Switch off all star types except F, G, B and O. Move the cursor to the direction you want the distance you want. Have the info tab on in the galaxy map, click and select. After doing it a while you learn how far to move the mouse. Constantly check your "height" to ensure you are not going to far up or down depending on your destination. Sag A is 35 or -35 cant remember.
Route Plotting in the Core: an explanation
- Thread starter Esvandiary
- Start date
Switch off all star types except F, G, B and O. Move the cursor to the direction you want the distance you want. Have the info tab on in the galaxy map, click and select. After doing it a while you learn how far to move the mouse. Constantly check your "height" to ensure you are not going to far up or down depending on your destination. Sag A is 35 or -35 cant remember.
An interesting insight into this problem.
When I am plotting long trips I (like a lot of commanders) set to travel X amount in Y time. I calculate this bases on target final destination.
I assumed Nav computer was giving me distance based on as the crow fly (i.e. direct, not taking into account jumps twists and turns) e.g. Guan Zana heading for Sagittarius A* distance 25787.99LY.
My slow plotting problems only started around 2500LY to/from Sagittarius A*. Plotting 500LY to 1000LY steps with fastest route, as seems always use max jump range until last few systems.
When I am plotting long trips I (like a lot of commanders) set to travel X amount in Y time. I calculate this bases on target final destination.
I assumed Nav computer was giving me distance based on as the crow fly (i.e. direct, not taking into account jumps twists and turns) e.g. Guan Zana heading for Sagittarius A* distance 25787.99LY.
My slow plotting problems only started around 2500LY to/from Sagittarius A*. Plotting 500LY to 1000LY steps with fastest route, as seems always use max jump range until last few systems.
As a side note I can confirm that route plotter uses as the crow flies method to give you distance:
| Dist Shown (LY) | Dist Travelled (LY) | |
| Sagittarius A | 25,831 | 25,831* |
| QUEMEOU AQ-Y D11 | 28,625 | 29,014 |
| Pheia auscs AA-A H23 | 37,571 | 38,640 |
| Hypio Prao AA-A H16 | 39,347 | 40,440 |
| EORL AUWSY AA-A H72 | 45,592 | 46,970 |
| DRYI AOC AA-A H60 | 47,817 | 49,230 |
| GREAE PHIO AA-A H33 | 51,199 | 52,085 |
| FROARKS AA-A H22 | 54,072 | 55,265 |
| Bleae Aewsy AA-A H22 | 56,927 | 59,145 |
| NGC 6357 | 60,965 | 63,265 |
| cat's paw nebula | 63,650 | 65,965 |
| Home (Lave) | 69,050 | 70,610 |
I was taking screenshots of my route every 1000LY and I only noticed at Sag A* that I had 27 screenshots not 26 which is why that one is perfect at 25,831LY. All jump distances are cumulative.
Over the remaining 45,000LY I lost about 1,600LY to the route planner not flying "as the crow does" combined with my 1000LY screenshots usually being 995LY instead of perfectly 1000LY.
Take the screenshot thing into account (45x5) and I still lost around 1300-1400LY due to the as the crow flies distance calculations.
Last edited:
Nice work Esv, I must admit I was slighly baffled as to how the route plotting algorithm could be so sensitive to "magic" numbers (and be so bad just a few light years either side of them) but your explanation seems spot on to me.
This is actually of benefit to me at the moment. As many may know my aim is to land in Empire space having scanned exactly 3301 systems. At 15Kylies I was calculating that I would be about 300 systems short, with a direct route. So I thought I would take the direct route and 3 Kylies out make up the systems by switching to economical. Hwoever I am now 9.5Kylies away and am now about 250 systems short, so the ducking and weaving on the route is helping me make up for the shortfall.
Edit: I have also noted that now I am in relatively sparse areas, the number of jumps for 1,000Ly has increased from 36 jumps to 41 jumps.
Last edited:
Excellent post!!! +Repped!!
Although I have to admit I have to read it a couple of more times to fully understand whats happening with that formula, mathematically speaking, e.g. why divide by 4? ....why substract the distance to Sag A*? Is Dist to Sag A* a constant or a variable?
Feel free to answer if you are so inclined but I guess that a couple of hard looks might make the click for me.
However, I just wanted to share my experience with the plotter while visiting Sag A* as I don't know how this would fit the work presented here.
I had a smooth plotting going in. No delays, no problems whatsoever. I did come from above, high up, and positioned myself some 1,000ly AS EXACTLY ABOVE SAG A* as I could. Then I plotted. It was a 940 distance or 970. Cant remember.
What I do remember is that I found no lag -expecting some due to reports here in the forum.
Now, it was on my way out that the Turtle Plotter Syndrome hit me: I painstakingly plotted jump after jump of no more than 47 ly. I had a hunch it would get better after 1,000 ly. And that's pretty much what happened.
From my still limited understanding of what you are explaining here, shouldn't have worked the opposite way? Shouldn't I had trouble calculating the arrival due to star density, rather than the departure route instead where destination stars are more sparsely distributed ?
Although I have to admit I have to read it a couple of more times to fully understand whats happening with that formula, mathematically speaking, e.g. why divide by 4? ....why substract the distance to Sag A*? Is Dist to Sag A* a constant or a variable?
Feel free to answer if you are so inclined but I guess that a couple of hard looks might make the click for me.
However, I just wanted to share my experience with the plotter while visiting Sag A* as I don't know how this would fit the work presented here.
I had a smooth plotting going in. No delays, no problems whatsoever. I did come from above, high up, and positioned myself some 1,000ly AS EXACTLY ABOVE SAG A* as I could. Then I plotted. It was a 940 distance or 970. Cant remember.
What I do remember is that I found no lag -expecting some due to reports here in the forum.
Now, it was on my way out that the Turtle Plotter Syndrome hit me: I painstakingly plotted jump after jump of no more than 47 ly. I had a hunch it would get better after 1,000 ly. And that's pretty much what happened.
From my still limited understanding of what you are explaining here, shouldn't have worked the opposite way? Shouldn't I had trouble calculating the arrival due to star density, rather than the departure route instead where destination stars are more sparsely distributed ?
Last edited:
It's basically just a "good guess" based on the sort of plots that worked well for me.
The divide by 4 is just an arbitrary constant; the more jumps you do, the more distance you're "losing" (due to not going in a straight line) so that component is just a way of accounting for that.
As for A*, the distance is a variable - it's how far you are from A* at the time you're plotting. It's a crude way of estimating how dense the stars are; the closer you are to A* the denser the stars are, and thus the nearer a straight line you tend to be able to plot. So, the further out you are, the more you need to subtract. The multiply by 2 is arbitrary too - I was basically trying to come up with a simple calculation that approximately matched what had worked for me.
It could be that you happened to use a number that's relatively good for your jump range - it's a relatively big range that can plot quickly so it's not that unlikely - and I think is part of why some people "get lucky". You can afford to go 5-10Ly below the "limit" without much penalty; it's only once you go over the limit (which adds an extra jump into the route) that things get really bad, since that's the worst case - lots of really short jumps.
It'll still be painful in either direction - even 1000Ly out the stars are extremely dense. On the times I've gone, it's started to get slow about 12-13000Ly away from A* - although that'll be strongly dependent on jump range, I was in a 40+Ly Anaconda for two out of those three runs
Last edited:
It'll still be painful in either direction - even 1000Ly out the stars are extremely dense. On the times I've gone, it's started to get slow about 12-13000Ly away from A* - although that'll be strongly dependent on jump range, I was in a 40+Ly Anaconda for two out of those three runs
Thank you for the explanation!
Now that I think about it, I was able to get to Sag A* with no troubles or delays because of my approaching course: I was cruising over 2,500 ly above the galactic plane, keeping a high "altitude" until destination when I dived into the GC. That route benefited me due to the scarcity of stars available for the plotter. However, I also noticed that while the plotting time might have not suffered, it was taking me an inexorably long time to progress even 1,000 ly, taking me 45 or more jumps to advance that distance.
The reason: if I selected a star ahead, say 980ly in straight line at the exact same altitude, chances were there were not enough stars at that plane, making the plotter to descend few dozens of ly, cruise to advance, then bring the route back up to my desire destination, in a dive-stroll-climb vertically U shaped route.
So I descended to 1,750ly for the last stretch, after realizing that I was taking way too long time to my destination. At that altitude, the density of stars was dramatically improved, I was now advancing 1,000 ly in 35 jumps and the plotter didn't even feel it.
Aha, yeah that'd explain it - if it was having trouble finding stars to plot at max range at all, then you definitely won't have been in a dense enough area to run into this problem on the way in.
Good way of avoiding the problems though, if you don't mind going slightly out of your way!
Aha, yeah that'd explain it - if it was having trouble finding stars to plot at max range at all, then you definitely won't have been in a dense enough area to run into this problem on the way in.
Good way of avoiding the problems though, if you don't mind going slightly out of your way!
Yeah, definitely not for BBR Racers!! It worked for me because: 1) Sag A* was but a waypoint on a much larger exploration route, 2) Many others Sag A* visitors before the BBR had warned that the best approach to avoid density was from either above or below.
I was coming from ETA Carina Nebula, then turned up towards The Lighthouse, then turned into Sag A*. Thats when I started climbing up, about 20,000 ly away.
Last edited:
Please can we sticky this?
I will add to sticky thread under the guides section, until mods decide what to do with this
Backing out of the galaxy map would be really nice, but the problem is when your system gets stuck plotting a route, you have to kill the process.
Going with the formula and examples provided, it doesn't work in all cases. For me it suggests 967.6 ly which is not that much lower at all as suggested you might need to go. So that bit as well is puzzling.
It's a good effort, but I think it could have been written out better.
Going with the formula and examples provided, it doesn't work in all cases. For me it suggests 967.6 ly which is not that much lower at all as suggested you might need to go. So that bit as well is puzzling.
It's a good effort, but I think it could have been written out better.
That was changed in 1.3, I should update this to reflect that (although I heard a rumour that it had been reverted in 1.3.02... perhaps that person was mistaken!)
As I said (several times), it's all very estimated - the formula is just guesswork from me based on what's worked for me, you might have to adjust. The main take-away point is that there are "magic numbers" for each ship/jump range, so it's worth finding yours if you plan to be around the core for any length of time.
Last edited:
Well using the normal back out methods don't work on keyboard or an xbox controller, I can testify to that.
I know you said (several times) it's very estimated and hence people take the information with a grain of salt. With the examples provided those figures are not much lower than the 980 figure when you suggested to people they would need to go much lower.
I've done more experimentation and so far, the figure of around 500ly is plotting almost instantly for me (although no doubt that will change now ). It's strange, maybe if you're data is holding up, people need to divide by 2 to get it working quick.
I know you said (several times) it's very estimated and hence people take the information with a grain of salt. With the examples provided those figures are not much lower than the 980 figure when you suggested to people they would need to go much lower.
I've done more experimentation and so far, the figure of around 500ly is plotting almost instantly for me (although no doubt that will change now
). It's strange, maybe if you're data is holding up, people need to divide by 2 to get it working quick.
The tragedy of it all is that the alternative paths that zerg the algorithm will likely all be very close to optimal because stars are so dense. Anyone would be able to guess a halfway decent route, so we see the algorithm doing badly in a scenario where the solution is somewhat obvious.
I'd assume that the algorithm was evaluated and tested based on its performace in "sparse star sidewinder" scenarios, where you need to be able to correctly calculate routes that contain major detours. The "core" scenario appears to be much simpler, the algorithm would obviously work too, but then someone forgot to consider evaluation cost.
In the "core" scenario, as an emergency measure, it would help to just present the best guess after a set amount of calculation expense. For a more beautiful solution to the problem, please ask someone who knows combinatorial optimization better than I do. That field probably has an algorithm that will produce a route within a constraint like "95% of best" at minimal evaluation expense. (I think the expert will then start frothing from the mouth and yelling "Iä simulated annealing ftaghn!", takes a bit to get used to)
I'd assume that the algorithm was evaluated and tested based on its performace in "sparse star sidewinder" scenarios, where you need to be able to correctly calculate routes that contain major detours. The "core" scenario appears to be much simpler, the algorithm would obviously work too, but then someone forgot to consider evaluation cost.
In the "core" scenario, as an emergency measure, it would help to just present the best guess after a set amount of calculation expense. For a more beautiful solution to the problem, please ask someone who knows combinatorial optimization better than I do. That field probably has an algorithm that will produce a route within a constraint like "95% of best" at minimal evaluation expense. (I think the expert will then start frothing from the mouth and yelling "Iä simulated annealing ftaghn!", takes a bit to get used to)
The number the formula comes up with isn't the only number that will work, it's just the longest one (since that's normally most useful). If you replace the longest jump figure with a different multiple of your jump range, it should work. In theory you'd need to lower the amount you subtract from it too, but like I said - it's a pretty rough estimate, so who knowsI've done more experimentation and so far, the figure of around 500ly is plotting almost instantly for me (although no doubt that will change now