Michael Brookes
Game Director
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Ah, wow. I didn't even notice that. (I obviously hadn't done any mapping last night
)I think 2 digits is still workable, although we'll need to be more rigorous about checking for multiple locations that match the data. And we'll likely need more data. I imagine we won't be able to get the coordinates for anything very far outside the new capsule either. Other than by eyeballing/screenshotting them, at least.
- - - - - Additional Content Posted / Auto Merge - - - - -
We could use the eyeball/screenshot method to get accurate positions for a small set of stars, and use those as the basis for calculating more stars via the usual methods.
OK - Things might not look quite as bleak as I first thought.
I've just run random tests with:
- distances with 2dp
- 5 reference systems
- using the RMS method
Only 3.3% of results are not 100% correct (compared to a faked known p0 position)
(dang RMS hurts my test times....)
I'm gonna add the "search a cube of grid coordinates" after a candidate have been found, and see how much that influences the final results.
I've just run random tests with:
- distances with 2dp
- 5 reference systems
- using the RMS method
Only 3.3% of results are not 100% correct (compared to a faked known p0 position)
(dang RMS hurts my test times....)
I'm gonna add the "search a cube of grid coordinates" after a candidate have been found, and see how much that influences the final results.
Checking a cube around the suspected coordinate is a good start, but it's not foolproof. That was my initial method as well, and if I remember right it was a set of coords/distances you posted that convinced me that it wasn't sufficient . That was when I started to go down the path of more rigorously finding the bounds of the candidate region.
. That was when I started to go down the path of more rigorously finding the bounds of the candidate region.Nope it's not sufficient.
And before with 3dp, not really necessary in most cases.
But with just 2dp - things have kinda been turned upside down, as 2dp isn't (100%) sufficient either.
Before doing the "cube coordinate search (CCS)" I decided to run some more tests just with RMS, but increasing the number of reference systems (aka distances)
The results are sort of interesting.
It's interesting to notice the large drop from 5 to 6 - and then the diminishing returns on the rest.
And before with 3dp, not really necessary in most cases.
But with just 2dp - things have kinda been turned upside down, as 2dp isn't (100%) sufficient either.
Before doing the "cube coordinate search (CCS)" I decided to run some more tests just with RMS, but increasing the number of reference systems (aka distances)
The results are sort of interesting.
Code:
#ref
systems Errors
5 3.31%
6 1.75%
7 1.33%
8 1.17%
9 1.07%
10 1.02%It's interesting to notice the large drop from 5 to 6 - and then the diminishing returns on the rest.
Last edited:
Harbinger
Volunteer Moderator
5 reference systems will never be sufficient for calculating the coordinates from a source that uses precision to 2 decimal places. We'd require distance measurements to several more points of reference to be able to have confidence in the found coordinates.
At the moment it's kinda irrelevant though because we have no idea which stars have moved to new coordinates, been renamed or maybe even been removed altogether.
I think the only way we could proceed without a current csv list would be to go back to the Beta 1 list of 55 stars and build from that and even that is assuming the positions of those stars haven't changed in relation to each other or Sol.
At the moment it's kinda irrelevant though because we have no idea which stars have moved to new coordinates, been renamed or maybe even been removed altogether.
I think the only way we could proceed without a current csv list would be to go back to the Beta 1 list of 55 stars and build from that and even that is assuming the positions of those stars haven't changed in relation to each other or Sol.
Nah, you don't have to have more than 5. At least not always. The way you get confidence in the found coordinate is by ensuring it's the only grid-aligned coordinate in the candidate region
.Sorry if I'm sounding like a broken record here, but I think we pretty much have to have a rigorous search of the candidate region now, with the lower accuracy distances.
My point is that there isn't some required number of distances that will guarantee a good result. In some cases, 5 will work fine. In other cases, you'll need more than 5. It really depends on the positioning of the references, and even on where the star happens to be within the +/- .005 range. e.g. you get a stronger one-sided condition if the star happens to be near the edges of the +/- .005 range, rather than in the middle. So you might get 2 distances in the same general direction that have strong one-sided conditions on opposite sides (i.e. the star is close to the -.005 side of one distance, the close to the +.005 side of the other distance), and so the combination of the 2 gives a tight constraint for that dimension.
By doing a search of the candidate region, you can conclusively determine if you have enough data or not. (At least, assuming the data is correct
).That actually brings up another point - with the lower accuracy distances, it will also be harder to spot bad data. I suspect it's more likely now that a small typo in the data could result in a single "correct" position that matches the incorrect data, but isn't actually the correct position of the star. Previously, the incorrect distance would more likely result in no positions that exactly match the data, and thus raise a flag that something was wrong.
One constraint I can think of is that we should ensure that we get enough distances for a given star such that if any 1 distance is removed, it still results in the same single matching coordinate after searching the candidate region. I think this would ensure that there is enough redundancy in the data to be able to detect 1 incorrect distance. I'm not sure how onerous a requirement that would be though.
So on second thought, I think you're right. 5 probably isn't "optimal", once you start taking into account error detection
So on second thought, I think you're right. 5 probably isn't "optimal", once you start taking into account error detection
Running a megaton of tests atm, which start taking longer and longer, the more stuff(*) I throw at them.
And the more variables I try to test for... There's quite a lot by now (num ref stars, cube size, and the coming "abnormally large" test values)
-----
stuff(*):
- Such as testing if other coordinate sets will produce a "correct" result, when doing the reverse distance check in the end.
- (not yet implemented) Such at looking into what happens if one throws away ref stars having an "abnormally large" RMS (some testing probably also required to figure out what "abnormally large" actaully is) - and then try again.
The assumption being that those with "abnormally large" RMS are probably typos (or indeed maliciously input data)
------
After I've gotten my head into the mindset of it no longer being possible to always find a 100% reliable coordinate set (took half a day...) I'm no longer quite so sad.
*Because* : The coords we find, will be "good enough" for what they are needed for - Namely route(/trade) planning.
If a system is of by 1-2-3 1/32 in some direction - It really won't matter much.
(It's still mathematically rather unsatisfying - And I still grind my teeth a bit over that)
We should however consider some scheme of attaching an "error delta" to the published coordinates. Consumers can then decide for themself if they will trust it above a certain threshold or not.
Likewise - Same threshold can be used to maintain lists of "we need more/better distances for this list of stars" (to gradually grind down that "error delta")
Last edited:
Another option: use the eyeball/screenshot method for all stars. It's not *that* difficult to do
Another option: use the eyeball/screenshot method for all stars. It's not *that* difficult to do
A small wrinkle has been added to that. You no longer get the grids showing when you hold right mouse button to change height in the GM. It should however be possible to work out how the length in pixels of the up/down line, when fully zoomed in, relates to the fraction of a light year.
On the note of making some progress... I'm at the far 'left' end of the bubble. Actually I'm outside the rendering of the bubble by about 50 light years! The system in question is "col 285 sector zx-f b 12-4", and so far I've noted these distances:
Code:
col 285 sector zx-f b 12-4
34 objects (inc MS)
~ -322.3, 34.5, -95.7
Eranin: 314.07
Magec: 310.10
Sol: 338.02
Adepti: 254.39
Gliese 9843: 218.87
35 Draconis: 247.19
NLTT 50716: 237.69
HIP 110773: 205.33
47 Cassiopeiae: 241.59Edit: I checked if stars from ed-systems (RedWizzard's, right?) systems.json were still in the positions listed on latest 'git pull', turns out Mistana has moved. The others listed above are in that file and eyeball to be in the same place.
Edit 2: And that's distances to 9 systems.json systems eyeballed at the correct positions.
Last edited:
May I ask a really dumb question? Why we are doing this? For what purpose are we trying to determine the star coordinates?
If it is just for the intellectual exercise and for fun, then fine. But given that FD seem to have shown a willingness to enhance the GM into a major tool (as witnessed by the recent changes) including providing a route planning capability (albeit embryonic at this stage), what do we need these coordinates for?
Don't want to rain on any parade - but just wondering.
If it is just for the intellectual exercise and for fun, then fine. But given that FD seem to have shown a willingness to enhance the GM into a major tool (as witnessed by the recent changes) including providing a route planning capability (albeit embryonic at this stage), what do we need these coordinates for?
Don't want to rain on any parade - but just wondering.
To be honest, for me, it's mostly just for the fun of it
. I know the data is useful for various tools and all that, but I don't really use those tools much.Third party tools often end up better just due to a focus on them. It's not just about route planning, it's about factoring that into trade helper apps. It's about being able to make a pilot's log tool where you can annotate the map. It's about making a tool where explorers can share information. It's about being able to plan out a complicated circular route that takes in certain systems/stations. It's about being able to refer to a map when you're not necessarily in-game.
Also, yeah, the intellectual challenge
.There is, of course, a certain sort of person who is attracted to the likes of the X-Universe games, not to mention Notch's defunct 0x10^C project, purely because one can procedurally tell your ship(s) what to do, rather than having to manually sort out everything you might want to do.
The reason why a 3rd party tool still need some sort of route planning is that profit without the time taken to obtain said profit is meaningless. So at least a rough position in space is needed.
Here are some observations I made during last beta and a large number of stations with markets: First, using accurate route planning for each possible trade route was very expensive. Just taking the distance between the systems, dividing by ship max jump or ship optimal fuel jump usually give a rough enough estimate on that trade routes potential performance. 2 DP wont give you the exact internal location like in previous beta, but it give a position more then good enough for 3rd party trade tools and 3rd party nav tools.
I still find it more convenient to have a 3rd party tool up on my side screens while playing...
Oh and trading is back ...
Here are some observations I made during last beta and a large number of stations with markets: First, using accurate route planning for each possible trade route was very expensive. Just taking the distance between the systems, dividing by ship max jump or ship optimal fuel jump usually give a rough enough estimate on that trade routes potential performance. 2 DP wont give you the exact internal location like in previous beta, but it give a position more then good enough for 3rd party trade tools and 3rd party nav tools.
I still find it more convenient to have a 3rd party tool up on my side screens while playing...
Oh and trading is back ...
My point is that there isn't some required number of distances that will guarantee a good result. In some cases, 5 will work fine. In other cases, you'll need more than 5. It really depends on the positioning of the references, and even on where the star happens to be within the +/- .005 range. e.g. you get a stronger one-sided condition if the star happens to be near the edges of the +/- .005 range, rather than in the middle. So you might get 2 distances in the same general direction that have strong one-sided conditions on opposite sides (i.e. the star is close to the -.005 side of one distance, the close to the +.005 side of the other distance), and so the combination of the 2 gives a tight constraint for that dimension.
By doing a search of the candidate region, you can conclusively determine if you have enough data or not. (At least, assuming the data is correct
That actually brings up another point - with the lower accuracy distances, it will also be harder to spot bad data. I suspect it's more likely now that a small typo in the data could result in a single "correct" position that matches the incorrect data, but isn't actually the correct position of the star. Previously, the incorrect distance would more likely result in no positions that exactly match the data, and thus raise a flag that something was wrong.
One constraint I can think of is that we should ensure that we get enough distances for a given star such that if any 1 distance is removed, it still results in the same single matching coordinate after searching the candidate region. I think this would ensure that there is enough redundancy in the data to be able to detect 1 incorrect distance. I'm not sure how onerous a requirement that would be though.
So on second thought, I think you're right. 5 probably isn't "optimal", once you start taking into account error detection
Pretty well spot on, IMO. Searching the candidate region seems like the most accurate option. I like the idea of requiring a set of stars with redundancy of one distance but would that mean 5/6 stars in practice or more? Some testing required on that I think.
Personally I'm mainly in it for the intellectual exercise. There is still some value to the data for trading tools though.
But if trading tools are now the main focus then perhaps we should rethink a bit. Coordinates alone aren't that useful so maybe we should be collecting data such as stations/economy types/etc.
Also if it's all changing again for gamma then there isn't much point in worrying about getting the now.