1015
Forum
You are not logged in. Please login or register.
Search options
Perpetuum Forums → Posts by Der Feind
Pages 1
Posts found: 11
1 2011-06-30 18:34:32
Re: Win a Mk2 heavy mech of your choice (386 replies, posted in News and information)
2 2011-06-29 02:18:18
Re: Server load issues in the last 48 hours (377 replies, posted in News and information)
All your server are belong to whoever clicks their mouse the fastest.
3 2011-06-04 23:01:57
Re: Alternate ways to create a waypoint (9 replies, posted in Feature discussion and requests)
Would be nice to also have existing waypoints sorted by island like the geoscanner results, instead of (in my case at least) one huge list that keeps resetting to the top when you try to send a waypoint to someone.
4 2011-06-04 18:20:39
Re: Do geo scanning caches scan on the z axis (elevation) (19 replies, posted in Q & A)
i like it actually - i take my alt account place it at the first 5km scan of the artifact im going after, set the radar marking range to the displayed distance
then i find out the direction to go, and walk/drive until i see my yellow dot on the circle line - and yesterday i did my last scan standing exactly on the artifact. the distance on landmark list was exactly the one of the first scan.
because that circle doesnt take Z coordinates into account
If you triangulate, and you set each of your three charges off at a different altitude, the Z axis will be averaged into your distance calculations. I'm guessing that is how Alexander (or rather his program) does it.
5 2011-06-02 18:54:39
Re: Do geo scanning caches scan on the z axis (elevation) (19 replies, posted in Q & A)
I found a Cache at location 1260,917
From 1059,1073 distance was 2609.03m (I have 100+ % Accuracy); This location is relatively higher than the cache.
Computed 2D distance between 1059,1073 and 1260,917 is 2544.35 m a 64m Delta
From 1197,849 distance was 927m
Computed distance between 1197,849 and 1260,917 is 925.52m a 1.48m Delta
This scan was obviously close, and made from a relavtive position 'below' the cache.
The other difference is scans were made with 5k and 1k loads.
Just to mix it up, a third scan was taken at 'about' the same vertical height;
969,1146 Distance given 3764.91m Calculated distance: 3704.24m 60.67m Delta
From above: 64 m 5% Difference between calculated and displayed
From ~same: 60.67 m 2% Difference between calculated and displayed
From below: 1.47 m .2% Difference between calculated and displayedEach Tile is 10m from center to center. When measuring from tile 1,1 to tile 1,2, you'll get 10m, but from 1,1 to 2,2 you get 14m.
The further away, and the greater the 'angle', the higher the error.
This is proven out with one last scan, done at
976,915 (which is almost directly along the 'y' axis at the same elevation as the 927 m scan)
Displayed distance: 2834.66 m Calc. distance 2840.06 m which is only a 5.34 m delta and again a .2%So two scans from the same elevation have the same % difference...
The conclusion... 'Z' may play a role in determining the Displayed distance, as the % difference did change with changes in elevation, but remained the same when repeated from the same elevation.
Why I say 'may' is that the 60ish m from the same level should'nt have any % difference if the ONLY thing was Z.
I think the 'angle' of incidence also adds error, as the 'same level' scan was done at about a 45 degree angle the grid. If you stand in one spot, and click around you, you'll see that you get a 9-10m reading from tiles 90 degress to the grid, while at 45 degree's you get 14-15m; which is correct as it's displaying the hypotenuse from center-center.
In the end, even with 100% accuracy, you need to seperate your scans by at least 10% (20% would be better) off the originally displayed value if you are trying to triangluate.
You should be able to compensate for the "angle of incidence". With the difference in distance between side-by-side tiles and diagonal tiles being approx. 4m, determining the angle of the hypotenuse should allow you to add the variance to the distance.
d=sqrt ( a^2 + b^2) where a = (x1-x0) and b = (y1-y0)
For this example, assume a is greater than b.
You would obtain the angle by determining what percentage b is of a.
(100% would indicate a 45 degree angle)
Angle = (a/(b*100))
meters per square = 10 + (4 * .Angle)
Distance = (d * meters per square)
I have not tested this yet, just a thought.
6 2011-05-12 18:17:22
Re: Corp Financial Transactions bug? (7 replies, posted in Resolved bugs and features)
Thanks!
7 2011-05-12 18:03:02
Re: Lag & disconnects since 01.22. (86 replies, posted in Resolved bugs and features)
If you are having issues with Global Crossing, you can also check (to some extent) the ping times router to router, and router to host.
8 2011-05-10 12:34:38
Re: Lag & disconnects since 01.22. (86 replies, posted in Resolved bugs and features)
I have been having lags and disconnects since T.I. was released. Defragged, then erased and reloaded both clients.
This is what I saw May 9th between 6:30p and 7p EST.
http://img607.imageshack.us/img607/4396 … 007312.png
As I read it, It shows that the connection is good until it gets to Budapest, then shows the Perpetuum server was unreachable from there. Anyone please correct me if you see something different, but it appears the problem I am having is on the server side.
9 2011-05-09 12:21:10
Topic: Corp Financial Transactions bug? (7 replies, posted in Resolved bugs and features)
I click on corp management, then accounting. The corporate financial transactions list shows the proper balance, but does not list items in date/time order even after clicking the date column. The first page starts at present date, and list some items for the past 2 days for some corp members. The second page starts at present again and list the past 2 days, but lists other items for seemingly random corp members. It appears that all items are present, just in a non-sensical order. There is no ability to sort by date/time.
Also, if I open the corporate financial transactions window on two separate clients it will show the transactions in a different (random) order, but again the total dollar amount appears correct.
Removed and re-downloaded both clients, but still having the same issue.
10 2011-03-28 17:12:34
Re: Re-allocatable EP (8 replies, posted in Feature discussion and requests)
Just no!
By the time you've waited you can just skill up the other skills you wanted anyway. No skill is wasted :rolleyes:
A half miner, half fighter account that wishes to be fighter only has wasted EP no matter HOW you roll your eyes at it. Everything is too dynamic in this game to have a static EP system.
11 2011-03-28 15:35:30
Topic: Re-allocatable EP (8 replies, posted in Feature discussion and requests)
This may have been posted already, but I have searched and cannot find it.
I think that instead of re-rolling accounts, an option should be available to re-allocate EP.
For instance, have an REP counter next to the EP counter at the top of the screen.
For every EP earned, a REP point is earned. Once you have earned and equal amount of REP as the current level of any extension, you can use that REP to subtract one level from the extension and return the EP from that level to you for use somewhere else, but only after clicking ok on a list of functionalities you will lose by doing so.
Re-rolling only allows for new mistakes to be made that are irreversible. Re-allocatable EP will allow players to tune the game the way they originally intended to.
Posts found: 11
Pages 1
Perpetuum Forums → Posts by Der Feind
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
Generated in 0.065 seconds (93% PHP - 7% DB) with 6 queries