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

Sol centric vs Galaxy centric

I might have missed something (entirely possible), but I don't quite understand the need for converting the SB3 coordinates to being Sol-centric again.

Imo it seems better to stay with whatever FD uses - We might get future info dumps, or some stuff might even turn up ingame or... whatever.
Ie. it seems to me using the galaxy centric coords are more "future-proof".

So why are people gravitating towards Sol centric coordinates (or I'm I just miss interpreting that)

Personally, I'm sticking with the galaxy centric coords, since that's what we got in the dump. Although, as gazelle mentioned, it is useful to know the transformation between the 2, since the GM still uses sol centric coords
 
Sol centric vs Galaxy centric

I don't quite get that either. Apart from the fact I don't really know what else we could do. The procedurally generated systems might change in the gamma as mentioned by FDev. I expect they will change if they discover bugs, and fixing them would require more effort than changing the coordinates of some (for them and for most players) irrelevant coordinates (even if we'd love them unchanged).

I can very well understand the frustration, I don't really know what to do with my map either. Leaving it as it is, with Beta 2 coordinates is pointless, so I'll likely just replace them with the new ones provided by Michael Brooks. I spent the last couple of days improving my coordinate finder tool, at least this may be useful at some point (either after gamma or release).
 
It's completely irrelevant which system you use as you can easily convert between them. You should just specify which one you're using (and the offset to Sol) if you provide them for others. For my calculation program I've converted them all to integers.
 
The real problem right now is the double use of system names as Athan pointed out in post #986. Shouldn't they be unique?

@wolverine2710: Have you asked Michael Brookes about that?

I'd expect it's a bug. Anyone know if Athan put in a ticket?

No, I didn't. I was hoping someone, Wolverine perhaps, would have alerted MB to this, as he was already in contact. Confirm you want me to put a ticket in instead (remembering it might just get ignored in the initial triage process) and I'll make one. Or 'you' can feel free to make one yourself.

For all we know he's already read my posts about it in this thread.
 
It's not galaxy centric, as can be read here.

I have actually read that post before - and not forgotten either.

I just saw someone in here refer to the new coords as being galaxy centric - So used that terminology.

It's completely irrelevant which system you use
Utterly so.

It's more a matter of me having to finish the TGC - And have to settle on something to actually store in the DB :D

Which one doesn't matter as you point out - But I thought it would ease usage to go with whatever would require less CPU cycles to have to convert all the time for everyone.


So I'm now a bit torn - yes the GM map is (still - could change?) Sol centric - But those chiming in here seems to go with the Galaxy centric coords in their apps.

So unless I hear differently - I'll go with galaxy centric for the TGC (easy to change if need be)
 

Slopey

Volunteer Moderator
I can very well understand the frustration, I don't really know what to do with my map either. Leaving it as it is, with Beta 2 coordinates is pointless, so I'll likely just replace them with the new ones provided by Michael Brooks. I spent the last couple of days improving my coordinate finder tool, at least this may be useful at some point (either after gamma or release).

There really is no point trying to do this sort of mapping exercise until FD stop re-generating the universe, which won't be until the RTM phase (I can't stand the term Gamma), or proper launch. Once that's past however, and we can be confident the galaxy won't go and change on us, everyone can go nuts with mapping, and I'll add something for that into the BPC.
 
New star name? Ross 690

Distance to Jula Oh? 159.78
Distance to Igororai? 156.88
Distance to Markanomovoy? 144.21
Evaluated 2202 locations

----- After exhaustively searching around the candidate regions resulting from trilateration, it evaluted a total of 2202 locations, and found 7 matching locations.


This made me go "hmmmm".
As that doesn't match what I found in my last test post
The low ball outlier: Never did I get less than 51 candidates that passed the reverse distance check (on *all* distances)

So.. With just 2dp, reverse distance checking isn't worth much.

So did some testing/debugging on that particular set of distances posted by JesusFreke.

And found a rather embarrassing bug...

Bug
Code:
    for (var r = 0; r < refs.length; r++) {
      var sumdistdelta = 0;
      sumdistdelta += Math.abs(refs[r].dist - +(Math.round(+(candidates[c].subtract(refs[r].coords).flength() + 'e' + edp))+ 'e-' + edp));
    }

Correct
Code:
    var sumdistdelta = 0;
    for (var r = 0; r < refs.length; r++) {
      sumdistdelta += Math.abs(refs[r].dist - +(Math.round(+(candidates[c].subtract(refs[r].coords).flength() + 'e' + edp))+ 'e-' + edp));
    }

Which means I'll have to revisit those last tests again....
I'll post what I find.

------

That bug found - and running the test for those distances:
I only find 4 sets of coordinates that will match (this with a 17^3 cube around the candidate found with trilateration)

And that *still* doesn't match what JesusFreke reported.

Being paranoid now - I'm posting which coordinates I've found to match - and JesusFreke if you could post your 7 sets I'd much appreciate it.

My 4 sets of coordinates, that pass a reverse distance check
Code:
-28.40625 ,47.8125 ,-21.96875
-28.40625 ,47.84375 ,-21.96875
-28.40625 ,47.875 ,-22
-28.40625 ,47.90625 ,-22

And for completeness, I'm using these coordinates to test
Code:
Ross 690   -28.40625,47.8125,-21.96875
Jula Oh    -184, 44.78125, -58.1875
Igororai    -176.25, 30.75, -71.59375
Markanomovoy -67.625, 17.0625, -50.21875
 
I wrote a little proof-of-concept utility this evening to try out this idea, along with a couple of related ideas, and it ended up working surprisingly well.
...
I'll try to get it cleaned up and released, although I might not be able to get it out until after the weekend. Maybe my description will at least spark some ideas that others can use :)

As promised (and earlier than promised :p), I updated my tool at https://github.com/JesusFreke/edist

The requirements should be the same as before: python 2.7, lmfit and numpy. If you're on windows, I recommend using the (topically named) anaconda python distribution which should have everything but lmfit, which you can install with pip (pip install lmfit).

It's a bit proof-of-conceptey, with some TODOs for various stuff that should be handled better.. :)
 
Which one doesn't matter as you point out - But I thought it would ease usage to go with whatever would require less CPU cycles to have to convert all the time for everyone.

Lets be generous and take 10 cpu cycles for a substraction. That would be 30 cpu cycles per system. All the systems from beta3 (2400) would then take up around 72000 cpu cycles to convert. How many GHz does your cpu have?
 
Last edited:
I have to pick one "format" (sol vs galaxy) or another to stuff in the DB, and there ain't much to differentiate going with one over the other (as it truly doesn't matter which one we go with) - So cpu cycles is what I could come up with.

If you have a more profound way of picking one over the other I'll gladly hear it.
 
I have actually read that post before - and not forgotten either.
I just saw someone in here refer to the new coords as being galaxy centric - So used that terminology.


Utterly so.

It's more a matter of me having to finish the TGC - And have to settle on something to actually store in the DB :D

Which one doesn't matter as you point out - But I thought it would ease usage to go with whatever would require less CPU cycles to have to convert all the time for everyone.


So I'm now a bit torn - yes the GM map is (still - could change?) Sol centric - But those chiming in here seems to go with the Galaxy centric coords in their apps.

So unless I hear differently - I'll go with galaxy centric for the TGC (easy to change if need be)

Personally I would prefer Sol-centric coordinates in TGC because it's what we've used so far so it requires fewer changes to our tools, and because the GM sectors are Sol-centric. Also part of the point of using JSON is that it's human readable so I think it is worth using the same coordinate system in the JSON files that the game displays - using galaxy-centric coordinates would essentially make the coordinates worthless for manual inspection of the file. For the same reasons I think we should continue to use real numbers rounded to 1/32 Ly.

I'm 95% sure the GM coordinates won't change: the maps were Sol-centric in FE2 and FFE and both those games also used galaxy-centric coordinates internally.

CPU cost of converting is negligible. There would be some cost for galaxy-centric coordinates in terms of JSON file size but I'd expect that to become negligible under compression.

The one-off hassle of converting any dump from FD doesn't bother me (and one of the two dumps we've got so far had Sol-centric coordinates anyway).
 
Last edited:
If you have a more profound way of picking one over the other I'll gladly hear it.

I would go with Sol-centric because that's what is displayed on the galaxy map and I don't think FD will change it. And can we please stop calling it galaxy centric, galaxy basic would be more accurate.
 
Sol centric vs Galaxy centric

I might have missed something (entirely possible), but I don't quite understand the need for converting the SB3 coordinates to being Sol-centric again.

Imo it seems better to stay with whatever FD uses - We might get future info dumps, or some stuff might even turn up ingame or... whatever.
Ie. it seems to me using the galaxy centric coords are more "future-proof".

So why are people gravitating towards Sol centric coordinates (or I'm I just miss interpreting that)

In game coordinates are SOL centric. So unless that changes in Beta, it should be the values you see in game grid that is also used for storage.
 

wolverine2710

Tutorial & Guide Writer
The real problem right now is the double use of system names as Athan pointed out in post #986. Shouldn't they be unique?

@wolverine2710: Have you asked Michael Brookes about that?

I'm planning to send Michael Brookes a PM today about that and a few small other things which have been discovered.
Its weekend so its possible it takes a bit longer to receive a response.

Edit: I'm also for Sol centric coordinates. Pretty much the same arguments as other cmdrs who prefer it also.
 
Issue in BETA3 dump, Thottacahuan "forum didnt like this part of the system name, think because it is slang starting with W for a male part (ending with ng with an a in between)) (in game name) is listed as only Thottacahuan in export.
 
Since there is a duplicate named "Chara", I'd expect there is a dupe "Naraka" too.

I am working on importing the data to my map, maybe I can check that myself later.
 
I'm another vote for Sol-Centric. As others have said it's what the in-game galaxy map uses. Also, other than the axis swap/inversion (FD have swapped Y and Z axes and inverted their Z axis) it's actually a real system used in science. See the Introduction part of http://arxiv.org/pdf/1010.3773.pdf (which talks about the old B1950.0 system, but also the newer J2000.0 one, aka FK5):

It is a heliocentric rectangular system with three principal axes in the direction of galactic center, galactic rotation, and north galactic pole.
 
Back
Top Bottom