Are you using the GetDistances function in the API? What parameters are you using that makes it fail?
EDIT: Nevermind, I just spotted the tgc.js file in your code.
Last edited:
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Are you using the GetDistances function in the API? What parameters are you using that makes it fail?
EDIT: Nevermind, I just spotted the tgc.js file in your code.
The tgc.js version will try to read the local cache files first (tgcsystems.json and tgcdistances.json) and then fetch any new data from the server. So it's typically using cr = 0 and date = whatever is at the top of the cache file. But the updatecache.js process I use to apply the corrections has been fetching all the data (cr = 0, date = '2014-09-09 12:13:14Z'). It's always been slow with the distances but now it seems to just never respond. I'll switch to reading the existing raw data from the file and only getting new data from the server. It should work ok, I'm just a bit paranoid about missing anything.
Just a quick GetSystems query with 10 LY cube around Sol was very slow, over 30 seconds. If that is not normal, then something is up...
EDIT: Well, the resulting data set was 10 MB, so maybe that's OK...
Last edited:
I suspect the volume of data is slowing both the filtering on the server and the actual download. The total set of distances is somewhere over 25 MB now. I did suggest to TornSoul to leave out unnecessary stuff like the coordinates in the distances output.
Did you get any response from TornSoul? Has anyone heard anything from TornSoul lately?
I made the suggestion back in gamma when we where discussion the design. I haven't tried contacting him lately but he hasn't posted at all this year so I think he's gone.
Yes, that's what I fear. Last post is from mid December. And I mentioned this several weeks ago: EDSC/TGC is getting slower and slower. Additionally trilateration seems to fail sometimes, recently. Had a small expedition yesterday evening, went out to T Tauri, had about 50 new systems. Some of them were quite OK, and some didn't show coordinates when my own site calculated them with no problem.
Just did a quick check, polling all distances from TGC doesn't work. Probably a timeout on TGC side. I increased the start date in some steps, and polling since mid February works: 6893 distances fetched from EDSC at Fri, 17 Apr 2015 10:13:24 +0200 in 512.19 seconds. Looks like a 10 minute timeout.
Edit: I just noticed my Apache & PHP had a timeout of 10 minutes set. I doubled it, but I doubt it is useful to wait 20 minutes for TGC distances. Maybe 40 next month? 2 hours in autumn?
Just did a quick check, polling all distances from TGC doesn't work. Probably a timeout on TGC side. I increased the start date in some steps, and polling since mid February works: 6893 distances fetched from EDSC at Fri, 17 Apr 2015 10:13:24 +0200 in 512.19 seconds. Looks like a 10 minute timeout.
Edit: I just noticed my Apache & PHP had a timeout of 10 minutes set. I doubled it, but I doubt it is useful to wait 20 minutes for TGC distances. Maybe 40 next month? 2 hours in autumn?
Last edited:
Very nice! I think I recognise my own trips out to S171 and the Coalsack.
- - - Updated - - -
Just did a quick check, polling all distances from TGC doesn't work. Probably a timeout on TGC side. I increased the start date in some steps, and polling since mid February works: 6893 distances fetched from EDSC at Fri, 17 Apr 2015 10:13:24 +0200 in 512.19 seconds. Looks like a 10 minute timeout.
Edit: I just noticed my Apache & PHP had a timeout of 10 minutes set. I doubled it, but I doubt it is useful to wait 20 minutes for TGC distances. Maybe 40 next month? 2 hours in autumn?
It's definitely a problem at his end. I've also been unable to fetch the whole set of distance data and I know the connection is not timing out at my end.
Anyone who needs a complete set of data can grab tgcdistances.json from my github repo (or tgcdistances-raw.json if they don't want my fixes applied).
I see what you're doing, Maddavo. LOL
I should have thought of that.
I should have thought of that.
Last edited:
LOL, too funny. Signing the galaxy are we?
HAHA! I was wondering how long it would take for someone to discover. LOL!
Houston, we have a problem.
Some weeks ago I found two small differences of 0.01 Ly between the distance displayed ingame and the calculated distance. I read about the precision ingame being 32 bit, and my PHP uses 64 bit, so I searched for a way to screw the PHP precision down to 32 bit. I found it, using pack() and unpack(). After that my PHP script calculated the same distance as the ED client shows ingame.
To be sure I verified some hundred calculated distances, and everything was fine. UNTIL NOW!
System Ys, located at (70.21875/-137.40625/63.6875), and System Col 359 Sector PJ-U b47-1, located at (-301.5625/255.25/1136.65625). Both verified by 10 or more correct distances. Maddavo reported the distance to be 1201.53 Ly two days ago, and I traveled there to verify. He is correct.
sqrt(pow(2247+9650,2)+pow(8168+4397,2)+pow(36373-2038,2))/32 = 1201.52493398688, gets rounded to 1201.52 Ly. Anyone got an idea why the distance gets displayed as 1201.53 ingame?
Some weeks ago I found two small differences of 0.01 Ly between the distance displayed ingame and the calculated distance. I read about the precision ingame being 32 bit, and my PHP uses 64 bit, so I searched for a way to screw the PHP precision down to 32 bit. I found it, using pack() and unpack(). After that my PHP script calculated the same distance as the ED client shows ingame.
To be sure I verified some hundred calculated distances, and everything was fine. UNTIL NOW!
System Ys, located at (70.21875/-137.40625/63.6875), and System Col 359 Sector PJ-U b47-1, located at (-301.5625/255.25/1136.65625). Both verified by 10 or more correct distances. Maddavo reported the distance to be 1201.53 Ly two days ago, and I traveled there to verify. He is correct.
sqrt(pow(2247+9650,2)+pow(8168+4397,2)+pow(36373-2038,2))/32 = 1201.52493398688, gets rounded to 1201.52 Ly. Anyone got an idea why the distance gets displayed as 1201.53 ingame?
I think from memory the sqrt is rounded before the division by 32 and then rounded again to get the final in-game distance. I'm sure it's somewhere in this thread.
round(sqrt(pow(2247+9650,2)+pow(8168+4397,2)+pow(36373-2038,2)),2)/32 = 1201.525 -> 1201.53
The "round to nearest 1/32" is an upshot of how single precision ends up representing the values, but that isn't intrinsically always going to be what happens with single precision values, certainly not in the case of small values (where the integer part is small enough that more bits can be used for the fractional part).
I first re-created what the game gives for distances by specifically forcing use of the 32-bit precision FSQRT/SQRTF function/assembly instruction, rather than plain SQRT which will be 64-bit on most modern systems, i.e. just forcing your inputs to single precision floats might not be enough, you need to use the function that internally is all single precision as well. I do believe some people had success with forcing values to single precision before and after SQRT though, but it is not safe to just assume that rounding to nearest 1/32 will be the same.
If your programming language of choice doesn't allow you to force 32bit/single precision values then you'll have a problem (actually true of perl as best I could determine).
When calculating distances the SQRT is the only floating point operation. Internally coordinates are stored as 1/32 Ly, so I store them as INT. When I substract, square and add them, they're still INTs. And even if I divide them before substracting, the resulting precision is still 100%.
But your post gave me a very useful hint. I remember that the coordinates were displayed with 3 digits decimal precision during some beta phase, so I will try to round them to three digits, then round them to two. Not sure if this will help, but I'll investigate.. Thanks!
Edit: The rounding to three, afterwards to two, removed some errors and brought some more new...
Last edited:
There were some changes, that's true. Ditibi has been moved, a few were renamed. Nothing really serious.
Yes, this is a very promising start. I know Themroc, and we wrote several mails. Actually EDDB is collecting names & coordinates from EDSC, and so it collected several errors from EDSC. RedWizzard & myself are trying hard to remove or correct the errors, but Themroc seems to focus on different things. Well, this is not an offense or criticism - Themroc may have tons of other things more important to do. RedWizzard & me focus on coordinates, and hopefully Finwen will make a testing version of EDDiscovery, using my API. Would be marvelous, because no more spelling errors, and EDDiscovery could ask the commanders to verify some distances to other systems where we need them, like my website does.
Right now RedWizzard's JSON contains one new error, coordinates of Col 173 Sector IM-D b28-1 are wrong, AFAIK. Themroc removed some EDSC errors, he is down to 5 coordinate mismatches right now, and 9 locations with question marks. Anyway I guess we're on the right track! ;-)
Funny thing: When I started this project several months ago, I began to cooperate with Sngerous, and the first name was EDDB. Some relicts at my site may still spill out the name. Renamed to Auriga then on behalf of Sngerous, but a few weeks ago we split, and now my site has no real name.