Yes, but the tool using the distance data would have to take that into account. Distance between stations would still enable finding the most efficient routes. Distance from star to station is most important when doing pre-gamma style trading. And is more important now that you might have a choice between two stations that using one over the other could shave precious time off your trade runs.
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
I've been thinking about how to collect all the stars in an area. I know the idea of a 20LY cube has been mentioned before, and I've tried finding all stars within a cube in the galaxy map.. and it just doesn't seem to work well for me.
Another idea would be to get a list of all the names all stars from the navigation panel, and store them along with the central system. Then, you can assume that all stars within the sphere based on the furthest star in the list are known. And then, we would need a system that would be able to find areas not yet covered by the set of overlapping spheres, and to suggest new stars to get the list of nearby stars from. And if we want some redundancy, to help make sure we don't miss a star because someone accidentally didn't enter it from the list, we could ensure that there are 2 or more spheres that cover everywhere.
Of course, there's a step missing in there, where you have to get the coordinates of the stars in the list, otherwise you don't know how big the sphere is - unless we have the player enter their current jump range as well. But we would need to figure out exactly what "range" to use there - i.e. how the game determines the max distance of stars to show in the nav panel. It's not just the current jump range, because, iirc, you sometimes get a couple of stars that are red at the very bottom of the list, even with an empty hold. At least, assuming you have a jump range < 20LY. If it's > 20LY, it's easy, because I believe there's a hard limit at 20LY, although I haven't verified this in gamma yet - as my current range is 19LY.
(Edit: duh - you could have them enter the distance to the furthest star.. and the assume the most conservative distance. i.e. 18.45 for a distance of 18.5)
Another idea would be to get a list of all the names all stars from the navigation panel, and store them along with the central system. Then, you can assume that all stars within the sphere based on the furthest star in the list are known. And then, we would need a system that would be able to find areas not yet covered by the set of overlapping spheres, and to suggest new stars to get the list of nearby stars from. And if we want some redundancy, to help make sure we don't miss a star because someone accidentally didn't enter it from the list, we could ensure that there are 2 or more spheres that cover everywhere.
Of course, there's a step missing in there, where you have to get the coordinates of the stars in the list, otherwise you don't know how big the sphere is - unless we have the player enter their current jump range as well. But we would need to figure out exactly what "range" to use there - i.e. how the game determines the max distance of stars to show in the nav panel. It's not just the current jump range, because, iirc, you sometimes get a couple of stars that are red at the very bottom of the list, even with an empty hold. At least, assuming you have a jump range < 20LY. If it's > 20LY, it's easy, because I believe there's a hard limit at 20LY, although I haven't verified this in gamma yet - as my current range is 19LY.
(Edit: duh - you could have them enter the distance to the furthest star.. and the assume the most conservative distance. i.e. 18.45 for a distance of 18.5)
Last edited:
Right, I'm not saying that having that data isn't useful, just that I don't think trading in-system would necessarily be more ideal than trading between systems. I think the "dream" situation might be 2 systems with stations <50LS from the star.
Out of curiosity, do we know what time scale the solar systems move at? Is it "real time", such that if the orbital period listed in the game is 400 days.. it actually takes 400 real days to make a full orbit?
There seem to be two limits: mass and fuel. I'm not sure how the fuel limit works, I occasionally got a warning about my attempted jump exceeding my 0.60 fuel limit or something.
The dream situation is 2 stations about 0.20Ls apart, each orbiting a planet with roughly the same orbit. I'm not sure how those can exist, but they do, and it's beautiful (according to my wallet)
For a simple way, for the user, to enter star data.
1. System asks for name of closest star, and distance
2. If the system doesn't know about that star it asks for second closest and so on.
3. When the system knows the star it has a very rough position (with an error margin of the disrance to the first star)
4. System then selects and lists suitable systems for the user to povide distance to.
As long as the user starts in a known system he should never be more than one jump away from a known point, is that good enough to select good sysyems for the calculations?
1. System asks for name of closest star, and distance
2. If the system doesn't know about that star it asks for second closest and so on.
3. When the system knows the star it has a very rough position (with an error margin of the disrance to the first star)
4. System then selects and lists suitable systems for the user to povide distance to.
As long as the user starts in a known system he should never be more than one jump away from a known point, is that good enough to select good sysyems for the calculations?
I plan to verify all the systems in systems.json this way. But at the moment I'm busy playing
This is pretty much what I did at the end of beta 2. Basically I kept a list of visited systems and used that to ensure I'd seen each system I knew about in the nav panel, recording any new ones as I went. It was slightly flawed because it relied on good coverage of the pill with known systems but it worked pretty well (even with the bug that caused some systems to only appear on the galaxy map). My unimplemented extension was going to be to track the individual 1/32 Ly grid locations that had been seen via the nav panel.
I've confirmed the nav panel still seems to be limited to a max of 20LY - and also to a max of 51 (51? really? off by one error somewhere?) systems. So the coverage sphere would need to be based on the star that's the furthest away.. not on the ship's range.
Amusingly, 51 stars isn't nearly enough for a full 20LY in some cases. I'm in a system right now that must be in a dense-ish area. The 51st star is only ~15LY away.
Last edited:
That max number of items limit did complicate the job rather a lot in beta 2 (I think the limit was lower then). I started out assuming I was covering 20 Ly spheres and later realised I couldn't count on that.
The best thing to do is get a 20LY FSD. In B3 the cutoff was on number of entries in list, so got more systems on list before scanning for planets...
The red system at bottom even if empty cargo is most likely due to rounding (7.58 in list, 7.65 jump capability with 100% fuel).
This is how I explore: (When I faceplant star, I usually go 0% trottle, get star in back and drop out of SC, its annoying to get interdicted while using maps... So far not been jumped while drifting in space at 0 speed)
1) Bucketlist for cube. Close to impossible to complete without +12LY jump range, much easier to get complete list with +20LY.
2) To find new systems: Compare distance list of what I have to distance list in game. I save these distances to DB, and will start sending to EDSC when I can start getting the +20LY lists. Also gathering SOL distance could be usefull.
2 *) New system: Note down system information, do a 1 off coordinate calculation. I'm using my html5 screenshot grid method, but could just as well be done with trilineration and 4 known systems. The goal here is to get 1) populated.
3) System view. Note down stations and faction.
4) Back in list, target station to get distance and station type
5) Visit each station to get market data, check if have black market, note down what ships are for sale (right now it looks like all stations in a system sell the same ships), note down what modules are on sale.
Now I have a system with complete data. Exploring in the game sense is something I will not do until I have A modules for discovery and surface.
- - - - - Additional Content Posted / Auto Merge - - - - -
Moving methodical between systems noting down the data should get you all the systems. It might start to fail when get out in less dense space. It takes a long time to complete a 20LY cube tough. And that Escape button is grinding my nerves...
Hah, I'm not *nearly* that patient
. My goal is to find the coordinates for as many stars as possible, as quickly as possible, and to ensure that I get full coverage for some areaThen just jump from system to system, skip stations and details, but you need to maintain that list of distances on each visited system.
If you look at within smaller area, you might get away with jumping between 4 known systems and noting distances for stars you are interested in. I'm not sure this is a faster way, and its for sure more suspect to errors and oversight.
You best bet is to go to the task in a methodical way and share the data and hope other do the same.
As said, I will implement post to EDSC from my personal database once I get a upgraded enough ship and have mapped out my first Cube. When that is depends on time I have to play, or if a/the Doomwipe happens again and such things.
I was thinking recording modules would be a nightmare, but it turns out it is actually a pretty fast thing to do. Market data is still the big ugly time consumer. To enter a completly new market takes me 7 minutes 30 seconds. Along with unknown system gathering. That part is not that big with 4-5-6 systems in a sidewinder, but I know that once that 51-item list is fully populated nearly every new visit to a system turns into repetetive data gathering. If I could get that OCR of the list working I would just skip taking coordinates. I would just jump from system to system and let it trilinerate when have enough data. But right now, doing it the most time efficient way includes getting that rough placement of each new system found.
If you look at within smaller area, you might get away with jumping between 4 known systems and noting distances for stars you are interested in. I'm not sure this is a faster way, and its for sure more suspect to errors and oversight.
You best bet is to go to the task in a methodical way and share the data and hope other do the same.
As said, I will implement post to EDSC from my personal database once I get a upgraded enough ship and have mapped out my first Cube. When that is depends on time I have to play, or if a/the Doomwipe happens again and such things.
I was thinking recording modules would be a nightmare, but it turns out it is actually a pretty fast thing to do. Market data is still the big ugly time consumer. To enter a completly new market takes me 7 minutes 30 seconds. Along with unknown system gathering. That part is not that big with 4-5-6 systems in a sidewinder, but I know that once that 51-item list is fully populated nearly every new visit to a system turns into repetetive data gathering. If I could get that OCR of the list working I would just skip taking coordinates. I would just jump from system to system and let it trilinerate when have enough data. But right now, doing it the most time efficient way includes getting that rough placement of each new system found.
Thank you. I added a system but it didn't tell me the co-ordinates?
Code:
Good job commander! Thank you for your assistance.
Trilateration un-succesful - Found multiple candidates.
Distance added, but failed to verify coordinates. Dist: LTT 16764->Yanyan: 70.42 LY.
Distance added, but failed to verify coordinates. Dist: LTT 16764->Styx: 85.26 LY.
Distance added, but failed to verify coordinates. Dist: LTT 16764->Rakapila: 92.25 LY.
Distance added, but failed to verify coordinates. Dist: LTT 16764->i Bootis: 84.57 LY.
Distance added, but failed to verify coordinates. Dist: LTT 16764->Eranin: 82.93 LY.
System added. - LTT 16764
Success
Submitting data.Yeah, I'm not going to visit every system, that's pretty ridiculous if you're just getting the coords. All you need is a big list of star names, and then go to some arbitrary set of known stars and get the distances to all of them. With the proper algorithm to determine which unknown stars still need more data, etc.
So to do say, 100 stars, you would need to grab the nav panel data for somewhere around 2-4 stars, depending on overlap. Say.. 5 minutes a star, so 20min, plus another 5 for jumping. And then, you have to get the distances to them all from ~6 systems, so 600 distances @ 5s each = 50 minutes, plus another 10m or so for jumping. So, 100 stars in around an hour and a half to 2 hours?
Has anyone done a rough estimate on the volume of inhabited space? I wonder how many stars we're talking about.. tens of thousands? Hundreds of thousands?
"Trilateration un-succesful - Found multiple candidates."
It wasn't able to nail down the co-ordinates yet, it needs more data. It should have remembered the distance data you've given it though, so if you can add more for the same target system it might eventually be able to accurately calculate co-ordinates.
Thank you. So I'm not wasting my time if I keep punching in data of systems I'm visiting around where I've started?
What I am curious to know is which tools are currently using the distance resources... I too, have been trying to add systems as I encounter them when using Thrudds. The issue is I don't know how long to wait before they are updated on the back end to be provided on the front.