Route Plotting in the Core: an explanation

Filters don't apply. I filter out non scoopables and my route takes me to brown dwarfs fairly regularly. Been doing that since at least 2.0.2. Probably since always.
It would be far too easy if the filters applied and fuel rats would be out of a job
 
Filters don't apply. I filter out non scoopables and my route takes me to brown dwarfs fairly regularly. Been doing that since at least 2.0.2. Probably since always.
It would be far too easy if the filters applied and fuel rats would be out of a job

This. Filtering out the stars only removes them visually from the gal map to make plotting easier, all stars will be included in any route plot. It is about time we could use manual waypoints, but then I can always dream.
 
This. Filtering out the stars only removes them visually from the gal map to make plotting easier, all stars will be included in any route plot. It is about time we could use manual waypoints, but then I can always dream.

Or tell the plotter to plot a route but don't include unscoopables...

Frawd
 
By far the best would be to just have it respect what star types you have filtered. Then it would also be useful when you're actually trying to only hit a bunch of non-sequence stars in a row. Not that I condone the soulless grind that is neutron star farming... :)
 
There was an update to the plot route routine in one of the recent updates. Perhaps this fixed a couple of the problems that it had (route plotting in the core and losing the route as it was replotting the route if you opened the galmap with an existing route)
 
Just had my first bash with your calculation and wow! what a difference it makes. I'm currently 9Kylies out and the optimum jump disatance was 950, i chose a destination 951 and i don't think i've ever seen a route plot so fast!

thanks alot Alot

fly efficient!
<-lightspeed->
 

Viajero

Volunteer Moderator
*Mod hat off

Silly questions:

Couldnt FDEV just replicate this logic in the route plot interface as an option?

Or better yet, alter the route planner algorithm behind the scenes to not needing to take the last few jumps with similar distance to previous?
 
Last edited:
*Mod hat off

Silly questions:

Couldnt FDEV just replicate this logic in the route plot interface as an option?

Or better yet, alter the route planner algorithm behind the scenes to not needing to take the last few jumps with similar distance to previous?

The short answer... Yes, the easy option to fix this would likely be about a half-hour job (not including testing, to be fair), and I've submitted bug reports against every major patch since 1.3 for this problem.

The easy solution should be pretty simple to implement and requires no UI changes: if the local star density is above a certain threshold (i.e. you are in the galactic core), don't bother with the fuel optimisation step at all. Just use the route that the A* algorithm already came up with; explorers probably don't care that the last jump in the route might be about 5Ly, as long as it plots in a reasonable time.
That'd mean any route would plot within about 5-10 seconds.
 
Last edited:
Thanks for this mate, I've made a video guide referencing this thread and going through the technique and equation, as well as your diagrams. Hope this helps!

Would appreciate any pointers and corrections and also feel free to link this in the OP if you think it's useful :)

[video=youtube;_ysqGpTD1NM]http://www.youtube.com/watch?v=_ysqGpTD1NM&list=PLmZswJzvjc8c7X6G3CtJLAGd6-XYem5gf&index=2[/video]
https://www.youtube.com/watch?v=_ysqGpTD1NM&list=PLmZswJzvjc8c7X6G3CtJLAGd6-XYem5gf&index=2
 
The short answer... Yes, the easy option to fix this would likely be about a half-hour job (not including testing, to be fair), and I've submitted bug reports against every major patch since 1.3 for this problem.

The easy solution should be pretty simple to implement and requires no UI changes: if the local star density is above a certain threshold (i.e. you are in the galactic core), don't bother with the fuel optimisation step at all. Just use the route that the A* algorithm already came up with; explorers probably don't care that the last jump in the route might be about 5Ly, as long as it plots in a reasonable time.
That'd mean any route would plot within about 5-10 seconds.


I personally think the route plotter shouldn't be so mad set on getting the best jump range fuel efficiency. Fastest is fastest, I don't care if the last jump is only 9ly :)
 
Thanks for this mate, I've made a video guide referencing this thread and going through the technique and equation, as well as your diagrams. Hope this helps!

Would appreciate any pointers and corrections and also feel free to link this in the OP if you think it's useful :)
I saw that, thanks very much! I posted in your Reddit thread, but it bears repeating... I completely agree with your choice to suggest trial and error, the main reason I came up with the maths is because at the time I didn't know about the fast-cancelling via Economical/Fastest. As you say though, it can help save some time by having a good idea of about where to start from.

I also greatly approve of the elastic band analogy. :D

I personally think the route plotter shouldn't be so mad set on getting the best jump range fuel efficiency. Fastest is fastest, I don't care if the last jump is only 9ly :)
When out exploring, I'm inclined to agree... The problem is when people are in the bubble with no scoop, that extra step might well be the difference between making your destination and a call to the rats. The difference it can make is surprisingly large! That actually goes even beyond what the in-game planner can generate - even with the fuel use optimisations, it's far from perfect.
Before now, I've had a 6-jump route that ran out of fuel after 4 via the in-game planner, and yet my out-of-game routing tools could come up with a route that'd just about get me there. (It was tight though, about a pixel of fuel left in the tank :D)

But yeah, that's why I'd be in favour of the step remaining there, but just be turned off in cases where it's likely to result in the slowdowns we've all seen far too much of. :p
 
Ive been using this recently (not that I was ignoring this amazing thread I just saw the words 'epic', 'wall' and 'maths' and decided to get distracted by something).


It is a very very very useful tool and has cut down sitting around getting cups of tea, hitting my pc and co-pilot (cat) and generally going all postal on my laptop because core route plotting is just generally 'gash' (Navy term meaning rubbish, so don't slap a profanity disciplinary on me Mods).

Loving it, its not that hard to understand and it works:)
 
Warning: this is a pretty epic wall of text. If you're not interested in plotting routes near the core without spending half an hour doing so, this probably won't be very interesting...


Update: If you prefer your guides in video form, check out this excellent summary by Dr. Kaii about how to get around this problem!


So, first up: it's widely known that ships with a large jump range (>30Ly especially) often have serious trouble navigating in the core: routes will often take half an hour or more to plot, lagging the game horribly as they do so.
I believe I've found a solution for this, and I have a reason as to why it works. If you just want to know how to plot, just read the first part: for why I think it works, read further on...

Evidence that it works: I recently did a Buckyball A* run where my entire time spent route plotting came to a bit under 18 minutes, for 30 plots.

So, first up: you'll need the following; all examples assume a jump range of 35Ly.

N is the maximum number of full range jumps you can do within 1000Ly - e.g. 1000 / 35 = 28.57..., so N = 28
M is the distance travelled by that number of jumps - e.g. 35 * 28 = 980
D is the distance you are from Sgr A*, in 1000Ly - so if you're at about 15k from A*, D = 15

Plot = M - ((N / 4) + (D * 2))

Now, you're probably thinking "MATHS?! I didn't come here for maths!", and that's fine. This isn't exact anyway, it's a half-decent approximation I just made up based on what I've experienced. You might need to go a little higher or lower than this suggests to get fast plots. It's just a guide.
What it means is that if you have a "max optimal range" of 980Ly, you need to plot much lower than that on the edges of the core if you want to get a good plot.
Let's plug some numbers in at various distances:

15k from A*: 980 - (7 + 30) = 943
10k from A*: 980 - (7 + 20) = 953
5k from A*: 980 - (7 + 10) = 963
0k from A*: 980 - (7 + 0) = 973

<snip>

OMFSM! It works! :eek:
I was at Waypoint 11 about 2 LY from Sag A* and I jst plotted a 983 LY route in about 4 seconds.
Have some rep!
 
Here's how they should really make it work:
  1. Route in the direction of your target until it hits an unscoopable system.
  2. Route backwards from the target towards the unscoopable system until it's within 1 jump.
  3. Connect the two routes.
  4. If the distances are obliging (edit, and have the mats), ask if you would like to automatically use an FSD injection to skip the unscoopable system.

It'd also be nice to just always get asked if I'd like to inject in order to bypass an unscoopable system, at the time that I initiate the jump. As it is now, injection isn't useful to standard travel.
 
Last edited:
Here's how they should really make it work:

Hate to say it, but that introduces a lot more complexity than just not doing the fuel check. If you're doing something like that, why not just add an option such that filtering the galmap also filters which stars are available for routing? There, no more unscoopables on your routes. :p

I agree that a better way of doing "fully boosted" routes would be helpful, though.
 
Last edited:
Back
Top Bottom