10 ly?
anyway, if all breaks down, plot the final leg manually one jump at a time.
Route Plotting in the Core: an explanation
- Thread starter Esvandiary
- Start date
10 ly?
anyway, if all breaks down, plot the final leg manually one jump at a time.
Typo. I meant 10K LY. So I expect I ain't seen nothin' yet for star density.
Not being able to stop routeplanning is driving me mad. I have written down the multiplication table for my Asp's range, like 40.36 80.72 121.08 etc and trying to plot routes that go to distances just shy of those. According to the OP's explanation that should work.... well it dont. not on my box at least.
Couldn't they at least not have the common courtesy of programming in a throttle on the amount of CPU route planning is allowed to suck. It's like 1992 again trying to make something that's giving a quarter frame per second do something. &#%(!
Couldn't they at least not have the common courtesy of programming in a throttle on the amount of CPU route planning is allowed to suck. It's like 1992 again trying to make something that's giving a quarter frame per second do something. &#%(!
Last edited:
Just use a simple formula like this:
Quickest plot range = (max jump range full tanks)*0.99 * (jumps you want to go)
Example, my ASP goes 35,54 on full tanks https://coriolis.io/outfit/asp/0p0tdFfliddsnf4----------3cv60i0i432i2f.AwRj4jmlRkg=.Aw18WQ==
Calculation for 27 jumps is just:
35,54 * 0.99 * 27 = 950ly ==> plots in 2 seconds anywhere in the core.
So if I want to go 10 jumps, it's
35,54 * 0.99 * 10 = 351 ly ==> plots in 2 secs aswell.
Then my absolute max would be 28 jumps:
35,54 * 0.99 * 28 = 985 ly ==> plots in 2 secs aswell.
Quickest plot range = (max jump range full tanks)*0.99 * (jumps you want to go)
Example, my ASP goes 35,54 on full tanks https://coriolis.io/outfit/asp/0p0tdFfliddsnf4----------3cv60i0i432i2f.AwRj4jmlRkg=.Aw18WQ==
Calculation for 27 jumps is just:
35,54 * 0.99 * 27 = 950ly ==> plots in 2 seconds anywhere in the core.
So if I want to go 10 jumps, it's
35,54 * 0.99 * 10 = 351 ly ==> plots in 2 secs aswell.
Then my absolute max would be 28 jumps:
35,54 * 0.99 * 28 = 985 ly ==> plots in 2 secs aswell.
Last edited:
yesyes, i had zero problems before engineering using the formula...
routeplotting gets new in 2.2. - let's hope that new plotting can deal with jumpranges up to 60 ly ....
So it looks like there were upsides to taking a Python with just a 20.9LY jump range. While the journey might have taken longer, I will have probably scanned more systems and had fewer frustrating moments as I approached Sag A.
But I must admit: I didn't know about this thread - ignorance is bliss - and just got on with it. I rarely plotted the longest possible route due to acute boredom and broke down the journey to 250-500LY per session, always landing on a G-type system to do a DSS of all the planets.
I don't think I waited more than a minute for a plot at any time - though it did sometimes seem longer. Reading through some of the contents, the length of the jump session should make very little difference to the time taken to plot as the bottleneck is the last few calculations. Or is this a mistaken conclusion?
Once I was within 300LY I only plotted single jumps by selecting Economical routes (which doesn't flood the view with possible routes), picking a target, then switching back to Fastest. It may not have been the most efficient means of travel but I got to enjoy it so much I'm now on the way to Jaques. Really looking forward to the new features in 2.2.
But I must admit: I didn't know about this thread - ignorance is bliss - and just got on with it. I rarely plotted the longest possible route due to acute boredom and broke down the journey to 250-500LY per session, always landing on a G-type system to do a DSS of all the planets.
I don't think I waited more than a minute for a plot at any time - though it did sometimes seem longer. Reading through some of the contents, the length of the jump session should make very little difference to the time taken to plot as the bottleneck is the last few calculations. Or is this a mistaken conclusion?
Once I was within 300LY I only plotted single jumps by selecting Economical routes (which doesn't flood the view with possible routes), picking a target, then switching back to Fastest. It may not have been the most efficient means of travel but I got to enjoy it so much I'm now on the way to Jaques. Really looking forward to the new features in 2.2.
Last edited:
@walter2 "Reading through some of the contents, the length of the jump session should make very little difference to the time taken to plot as the bottleneck is the last few calculations. Or is this a mistaken conclusion?" - i think, you underestimate the deadly combination of jumprange and stardensity.
i guess, someone could provide a formula, but anyways with stardensity going up, the increase of options per ly jumprange increases non-linear.
i guess, someone could provide a formula, but anyways with stardensity going up, the increase of options per ly jumprange increases non-linear.
You might well be right - I am reliant on my own experiences.
I was working from the OP that suggests that the heaviest calculations involve the last three or four jumps. This would explain why the first 96/97% is calculated relatively quickly. The calculation time difference between 20- and 50-jump sequences seems negligible (my observations) and it's only the increasing number of options available in the last few jumps that cause the slowdown as you get closer to the core.
My 20LY jump limit means that I am roughly 30LY closer to my target when the last three jumps are to be calculated and have far fewer route options available.
But a predictive formula is only as good as its repeatability and there are a number of reports of failure. I would suggest that there are a number of factors that are not - possible cannot be - included in the calculation. Perhaps one of the most important is the pilot's tolerance of delay, an intangible that's very resistant to quantification. I also wonder if the calculations are on data that is held by the client; if data has to be imported from the server - either immediately before or during the process - there is always the opportunity for lag to play a part.
And there's always the opportunity for a user of the algorithm to misunderstand how the factors involved inter-relate.
My jump range probably explains why I found it so relatively easy when others really did experience extended calculation times.
Last edited:
try my method. Simple multiplication. If you have a 40ly jumprange plot your route for 960ly, or 880ly, or 80ly. If its in the multiplication table for that jumprange it should work. So if its 41ly you can try 984ly.
That matches up with my observations; more data supporting this is from when the route planner inadvertently became "unlimited" during the 2.1 beta and you could route 20kLy+ (at the risk of crashing the client). If a route ended in the core, it would become treacle as you'd expect. If the route went through the core and out the other side, it'd always still plot relatively quickly.
I believe there's no server call involved - everything's already on the client. You're absolutely correct, though, that there are factors such a simple calculation just can't account for. It's basically a finger-in-the-air guess that works for the most common exploration jump ranges, but starts to fall apart a bit once that range goes too high or low (hence people having problems with engineered FSDs).
Yup, you're right on the money here - smaller distance over the final few jumps means way fewer possible valid routes for it to check, as you suggested earlier.
If that ever works, it's essentially by chance - probably by being about the right number for "n+1" or "n+2" jumps, e.g. doing 25/26 jumps for the straight-line distance of 24 jumps.
The numbers thrown out by my guess-y equation will go through such cases several times on the way into the core.
I've been meaning to throw a diagram together which might make it a bit clearer... Will see if I have time this evening.
Last edited:
Alright, here goes...
The following image assumes you're trying to plot in the core with a 40Ly range.
The green/yellow/red part is the time taken to plot at any given distance. The small green/red bars below the graph indicate the places where it's best/worst - the green part is the "magic number".
Note that although (as the diagram under the graph shows) we're doing 40Ly jumps the whole time, after six jumps we haven't quite reached 240Ly, because we're not going in a straight line. This is why just plotting at multiples of your jump range isn't a good tactic - it doesn't take into account for you "losing" distance due to always taking small detours every jump. With that said, it will sometimes work because eventually the amount of distance you've "lost" will add up to your jump range, which effectively resets it - then, from a magic number point of view, it's as if you haven't lost any distance at all.
The other thing to note is that the green bar is right next to the red bar. This means that having a magic number that's slightly too high is catastrophic - it results in the worst possible scenario, which could take hours to calculate. If you ever see it gets stuck on the dreaded "99%" this is likely what's happened.
On the other hand, going a bit too low isn't so bad - in the best case it'll make almost no difference and still plot quickly. At worst it might take a little while to work it out, but it won't be hours.
Hope that makes sense... Let me know if I can make any changes to improve it! I'll add it to the OP if people think it's helpful.
The following image assumes you're trying to plot in the core with a 40Ly range.
The green/yellow/red part is the time taken to plot at any given distance. The small green/red bars below the graph indicate the places where it's best/worst - the green part is the "magic number".
Note that although (as the diagram under the graph shows) we're doing 40Ly jumps the whole time, after six jumps we haven't quite reached 240Ly, because we're not going in a straight line. This is why just plotting at multiples of your jump range isn't a good tactic - it doesn't take into account for you "losing" distance due to always taking small detours every jump. With that said, it will sometimes work because eventually the amount of distance you've "lost" will add up to your jump range, which effectively resets it - then, from a magic number point of view, it's as if you haven't lost any distance at all.
The other thing to note is that the green bar is right next to the red bar. This means that having a magic number that's slightly too high is catastrophic - it results in the worst possible scenario, which could take hours to calculate. If you ever see it gets stuck on the dreaded "99%" this is likely what's happened.
On the other hand, going a bit too low isn't so bad - in the best case it'll make almost no difference and still plot quickly. At worst it might take a little while to work it out, but it won't be hours.
Hope that makes sense... Let me know if I can make any changes to improve it! I'll add it to the OP if people think it's helpful.
The magic number calculations works fine the lower your jumprange is, I had no issues when going in my 33ly asp or conda. But after dropping of a lot of cargo at jaques (for one of the CG) I had way higher range when going into the core.
And it does NOT WORK when you have 53.8ly range. According to the calculator I should have a magic number of about 934ly when i'm 7.5kly from the core, but this was not the case.
After much trial and error, and some calculations trying to add decimals, what I came up with was a magic number of 963ly.
963 is exactly 18x53.5 (or just a tad of my max range pr jump) or to math it out, it's 99.5% of your absolute max range fully fueled.
When using my new magic number I had no issues when plotting into or out of the core.
One of the issues I see is that with a higher jumprange, you need to be closer to the absolute max due to the number of possibles stars it has to calculate. If we think about the rubberband metaphor it's a bigger band.
And it does NOT WORK when you have 53.8ly range. According to the calculator I should have a magic number of about 934ly when i'm 7.5kly from the core, but this was not the case.
After much trial and error, and some calculations trying to add decimals, what I came up with was a magic number of 963ly.
963 is exactly 18x53.5 (or just a tad of my max range pr jump) or to math it out, it's 99.5% of your absolute max range fully fueled.
When using my new magic number I had no issues when plotting into or out of the core.
One of the issues I see is that with a higher jumprange, you need to be closer to the absolute max due to the number of possibles stars it has to calculate. If we think about the rubberband metaphor it's a bigger band.
I'm on the Nebula expedition, and recently started struggling to plot routes between waypoints 8 and 9 - the starfield is so dense D:
I've tried using this method/tool with some success (I'm still about 12k away from SA), but have actually had more success by just plotting routes that are multiples of my jump distance. They're almost instant.
Wonder how long it will last!
I've tried using this method/tool with some success (I'm still about 12k away from SA), but have actually had more success by just plotting routes that are multiples of my jump distance. They're almost instant.
Wonder how long it will last!
Yeah, as I said elsewhere the equation's a rough guess that gets it about right for (what at the time were) common exploration jump ranges - ~25-40Ly. Beyond that it starts to break down - not least because the overall behaviour of the route plotter is a bit different when it has much longer/shorter ranges to work with.
Yup, exactly... Not only does it behave a bit differently, but the margins are much tighter for it to be right!
I really hope the changes in 2.2 do fix this, as others have speculated...
As long as you've got a number that works, then you're golden - as things start getting even more dense and it starts getting slower, just bump that number up a bit and it should speed back up. You'll know if you've gone too high - it'll get stuck on the dreaded "99%"
Last edited:
Potentially exciting stuff from 2.2 changelog ...
Surely at least one of this changes ought to fix core route plotting?
Surely at least one of this changes ought to fix core route plotting?
The last one sounds most relevant (at least, most like my hypothesis about what was causing it)... But all of them sound at least somewhat good! REJOICE!