Discussion What is the most efficient way to crowdsource the 3D system coordinates

Thanks.

Example with 2 Systems:

G. Caeli',80.90625,-83.53125,-30.8125,
Geminorum',19.78125,3.5625,-153.8125,

D=162.636

What unity is that result? LY?

If you want to get the exact result that ED shows you need to use single precision floating point for the calculation. In Javascript you can do that by using fround:
Code:
// p1 and p2 are objects with x, y, and z properties
function eddist(p1, p2) {
	var x=p1.x-p2.x;
	var y=p1.y-p2.y;
	var z=p1.z-p2.z;
	var d = Math.fround(Math.sqrt(Math.fround(Math.fround(x*x) + Math.fround(y*y) + Math.fround(z*z))));
	return round(d,2);
}
 
I've just updated systems.json with about 150 new systems from JesusFreke.

There are currently 20,332 systems in the file, with 345 of them needed verification.
 
Are they added to EDSC too? I've adjusted my tool so I can get systems around me in a 60LY cube (using EDSC). Just 3 or 4 hours of grinding left for Type6 with A FSD, but my milkrun was starting to drop 4 credits on every end for every trip, so I might have to go scouting for another soon :/
 
Does EDSC check names case sensitive? This will be an issue with manually added data. I think I by accident entered a Lalande system with lower case l, and from how I read the return data it added the lower case l system even if already had the upper case L system.
 
Are they added to EDSC too? I've adjusted my tool so I can get systems around me in a 60LY cube (using EDSC). Just 3 or 4 hours of grinding left for Type6 with A FSD, but my milkrun was starting to drop 4 credits on every end for every trip, so I might have to go scouting for another soon :/

Assuming you're asking about the 150 stars I added - no, not yet. I had tried to submit the distances to the test instance of EDSC, but I kept getting errors for specific systems, even though other systems worked fine. I've PM'd TornSoul, but he's probably out for the holidays or something.

I'll definitely get them submitted to EDSC when possible.
 
Last edited:
Does EDSC check names case sensitive? This will be an issue with manually added data. I think I by accident entered a Lalande system with lower case l, and from how I read the return data it added the lower case l system even if already had the upper case L system.

I was considering this aswell, so I thought I would run a test

On the test database I have added system "Lahdedah" (with some distances), I then attempted the same query again this time using "lahdedah" and this is the response I got back:


"systems":[
{"name":"lahdedah"},​
{"name":"Lahdedah"}
]}

So (as long as the main DB is the same as the test DB) it appears that it is case sensitve
 
Last edited:
Are they added to EDSC too? I've adjusted my tool so I can get systems around me in a 60LY cube (using EDSC). Just 3 or 4 hours of grinding left for Type6 with A FSD, but my milkrun was starting to drop 4 credits on every end for every trip, so I might have to go scouting for another soon :/

I haven't added anything yet. I'll write some tools to do it in the next day or two.
 
FYI for everyone: I just found a star from Michael Brooke's dump that is missing in the game - LTT 4549. It doesn't show up on search in the galaxy map, there's no star at that coordinate in the GM, and it's not listed in the nav panel for nearby stars.
 
So (as long as the main DB is the same as the test DB) it appears that it is case sensitve

Ok, I think that needs to be changed. It's impossible to get the correct spelling without checking the log. While the "...Sector..." names have a common pattern (e.g. "Core Sys Sector CL-Y d145"), most people won't realise what the pattern is. Then there are cases like "44 Eta Librae" but "44 chi Draconis", and I bet no one would pick the capitalisation of "DzaliTemu" and "DzacaliTem". TGC should ignore case when adding but it would be good if there were some way for it to evaluate the different capitalisations and keep the name that is most likely to be correctly capitalised (in the past I've used the name with the most upper case letters provided they're not all upper case but that's not foolproof).

- - - - - Additional Content Posted / Auto Merge - - - - -

FYI for everyone: I just found a star from Michael Brooke's dump that is missing in the game - LTT 4549. It doesn't show up on search in the galaxy map, there's no star at that coordinate in the GM, and it's not listed in the nav panel for nearby stars.


That's Shinrarta Dezhra. I changed the name in my systems.json when I noticed. Interestingly you can find that system using any of these names:
Shinrarta Dezhra
Founders World
HD 105671
HIP 59296
Gliese GL 9391
... but not LTT 4549
 
Last edited:
Ok, I think that needs to be changed. It's impossible to get the correct spelling without checking the log. While the "...Sector..." names have a common pattern (e.g. "Core Sys Sector CL-Y d145"), most people won't realise what the pattern is. Then there are cases like "44 Eta Librae" but "44 chi Draconis", and I bet no one would pick the capitalisation of "DzaliTemu" and "DzacaliTem". TGC should ignore case when adding but it would be good if there were some way for it to evaluate the different capitalisations and keep the name that is most likely to be correctly capitalised (in the past I've used the name with the most upper case letters provided they're not all upper case but that's not foolproof).

- - - - - Additional Content Posted / Auto Merge - - - - -




That's Shinrarta Dezhra. I changed the name in my systems.json when I noticed. Interestingly you can find that system using any of these names:
Shinrarta Dezhra
Founders World
HD 105671
HIP 59296
Gliese GL 9391
... but not LTT 4549

Ahh, good catch! I guess I wasn't looking hard enough when I eyeballed for that coordinate in the GM :)
 
Ok, I think that needs to be changed. It's impossible to get the correct spelling without checking the log. While the "...Sector..." names have a common pattern (e.g. "Core Sys Sector CL-Y d145"), most people won't realise what the pattern is. Then there are cases like "44 Eta Librae" but "44 chi Draconis", and I bet no one would pick the capitalisation of "DzaliTemu" and "DzacaliTem". TGC should ignore case when adding but it would be good if there were some way for it to evaluate the different capitalisations and keep the name that is most likely to be correctly capitalised (in the past I've used the name with the most upper case letters provided they're not all upper case but that's not foolproof).

- - - - - Additional Content Posted / Auto Merge - - - - -




That's Shinrarta Dezhra. I changed the name in my systems.json when I noticed. Interestingly you can find that system using any of these names:
Shinrarta Dezhra
Founders World
HD 105671
HIP 59296
Gliese GL 9391
... but not LTT 4549

Hmm, when say hip and gliese, I notice the info panels now show hipp and gliese, could that mean that every "real database" entry name is mapped to something in game?
 
I was considering this aswell, so I thought I would run a test

On the test database I have added system "Lahdedah" (with some distances), I then attempted the same query again this time using "lahdedah" and this is the response I got back:


"systems":[
{"name":"lahdedah"},​
{"name":"Lahdedah"}
]}

So (as long as the main DB is the same as the test DB) it appears that it is case sensitve

Thanks for testing.
And yes the main DB is identical to the test DB.
The test DB is a complete backup (ie. it's overwritten) of the main DB made every 24 hours at 1:15 AM.


egg on my face for not considering this in advance :mad:
Really is a noob mistake on my part...

A quick check of the DB shows 25 systems occurring more than once - Which is really really bad...

I'll get started on fixing this immediately.
A quick glance at the code shows that I need to fix this in a lot of places actually :-(

I'll let you know when it's done.
 
Hmm, when say hip and gliese, I notice the info panels now show hipp and gliese, could that mean that every "real database" entry name is mapped to something in game?

Yes, those are real star catalog ids. Anything with those sorts of entries on the info page shouldn't change position even if they change the parameters on the procedural generation. Unless they find a mistake in their translation to ED coordinates, of course.

I don't know how completely they've imported those catalogs. Some of them are rather large: Hipparcos has nearly 120,000 stars, the Henry Draper catalog (HD...) has over 250,000. It looks like they haven't used the real big ones: USNO-B1.0 has over a billion objects and the Guide Star Catalog has nearly a billion stars.

There is a good online database you look up by any of these ids. E.g. http://simbad.u-strasbg.fr/simbad/sim-id?Ident=LTT++4549
 
Last edited:
I've PM'd TornSoul, but he's probably out for the holidays or something.

Urg - I always forget to check the damn PM's....

I got 11...

Working my way through them now...

EDIT: I've now added mail reminder on PM (someone hinted in PM (the irony) that that was an option)
 
Last edited:
I was considering this aswell, so I thought I would run a test

On the test database I have added system "Lahdedah" (with some distances), I then attempted the same query again this time using "lahdedah" and this is the response I got back:


"systems":[
{"name":"lahdedah"},​
{"name":"Lahdedah"}
]}

So (as long as the main DB is the same as the test DB) it appears that it is case sensitve

This should now be fixed.

Now I just need to clean up the DB...
 
DB updated.

27 duplicates removed.

No distance data was referencing any of the duplicates.

It does appear some distance data has not been saved however - ie. coordinates have been found for some systems, although not enough distances are actually in the DB.
I assume (hope) this can have occurred due to errors because of the duplicate names (lambda joins failing etc)

But it might be something else....
 
Last edited:
TGC should ignore case when adding but it would be good if there were some way for it to evaluate the different capitalisations and keep the name that is most likely to be correctly capitalised (in the past I've used the name with the most upper case letters provided they're not all upper case but that's not foolproof).
Yeah making something foolproof is most likely impossible - Hence I'm not even going to try tbh.

I'd be open to manually (well I'd script it) edit the DB if someone provides a list with names that need fixing along with what they should be corrected to.
 
Back
Top Bottom