Route Plotting in the Core: an explanation

[Esvandiary]

I have a feeling I'm doing this wrong. =/ According to the math, at a jump range of 39LY, at 11k from the core, my optimum plot is around 947ish. I still can't get it to plot quickly. I also have a question as to the plotting of shorter routes via this method? If I want to do a short hop to check out something neat looking, it seems to bog as badly as it does for a long route. I could use a hand to hold I think

Is your jump range exactly 39Ly? Little bits of a light year add up when you're multiplying by 25 or so... What percentage does it say when it gets stuck?

As for shorter hops, just change your M number so it's not (39 * 25), it's (39 * 10) for example, depending on how far you want to go.

 

[Cyberguts]

Sorry, but no. Neither method work for me. I've tried for a half hour again with multiple different systems in the right range. Nothing. It get very nervous and frustrated from such a slow and stuttering image so i rage quit and next time, i'm going back.

Ca't even play right now, so frustrated am i.

Its a shame the devs haven't fixed the problem properly yet.

I feel your pain....
I too have been having problems. The equation worked until I was 6kLy out from SagA and could only plot 420ly routes with my 41.5ly jump range AspX... Then, about 4k out; it started working again.

My problem now.... I'm 773ly away from SagA now and not even 110ly routes plot

 

[Nerwan]

It sounds then as if having a good amount of cargo space in your explorer build could be a good thing.. If you have unused cargo space, you can use the cargo slider to artificially reduce your jump range, forcing the route planner to think you can't jump as far.. It functions as a half way house between "efficient" route and "fast" route, but it might also work well for this.

Out of interest, how easy is it to visually see which way you're going once you're inside the core? I did wonder if manual route plotting using a macro to cycle through the systems might be possible as an alternative to using the route planner, but that would depend on being able to see which way the core was. Easy when you're outside the core, but possibly hard once you're inside it.. I don't know though since I haven't been there yet.

 

[The_Last_Bastion]

Thanks for the help on those questions, folks. I figured out I was mathing wrong. Got a 953ly plot in about 2.6 seconds. . This is totally awesome

 

[lionhead]

I feel your pain....
I too have been having problems. The equation worked until I was 6kLy out from SagA and could only plot 420ly routes with my 41.5ly jump range AspX... Then, about 4k out; it started working again.

My problem now.... I'm 773ly away from SagA now and not even 110ly routes plot 

Yeah i found out even 3 hops wouldn't calculate simply because the computer is calcualting too many routes.

What i did figure out is a more simple math equation that might work. See, i have a jumprange of about 30ly. So, i try to calculate routes that are within that multiplication table. So 900ly should calculate,so would 990ly and 999ly but 997ly for example creates problems(but less than 970ly). So if you have 41.5ly range you should be able to calculate 830ly for example, or 871.5ly, etc. But only if its exact or very close to it(like 830.4ly). 110ly wouldn't work as it isn't in the multiplication table, even though its much shorter.

Haven't tried that with such specific jump ranges though, but you could try. i hope i'm right. Unfortunately i only found out after i gave up and headed out of the core.

 

[Nerwan]

In computer science terms this is known as the shortest path problem. As you can see from the link, there's a number of possible algorithms for solving this type of problem and some of them are more efficient than others. They range from O(E) (meaning that the time taken will scale linearly with the number of possible routes to be considered in effect). To O(V^2) which would mean that the time taken would start to become exponentially more as the number of vertices (stars) to be considered increases.. My guess is that the algorithm used by FDev is not O(E) since it does not seem to scale linearly.. It might be that it isn't possible for them to use that one..

 

[Esvandiary]

What i did figure out is a more simple math equation that might work. See, i have a jumprange of about 30ly. So, i try to calculate routes that are within that multiplication table. So 900ly should calculate,so would 990ly and 999ly but 997ly for example creates problems(but less than 970ly). So if you have 41.5ly range you should be able to calculate 830ly for example, or 871.5ly, etc. But only if its exact or very close to it(like 830.4ly). 110ly wouldn't work as it isn't in the multiplication table, even though its much shorter.

That's basically what the equation does, except it tries to take into account that it won't be an exact multiple because the hops aren't (quite) all in a straight line - you're bouncing between stars either side of the straight line, which effectively loses you distance.
With that said, there's nothing to stop the calculation from ending up exactly one jump-range below that straight-line distance... Although in a straight-line you could do 830Ly in 20 jumps (assuming 41.5Ly range), it could just as easily be that you can do 830Ly in 21 jumps wherever you are... That will always happen quite a bit on the way into the core; initially you might do the same distance in 23 jumps, then 22 and finally 21... The "magic number" for a given jump count will rise constantly as the star density gets higher.

In computer science terms this is known as the shortest path problem. As you can see from the link, there's a number of possible algorithms for solving this type of problem and some of them are more efficient than others. They range from O(E) (meaning that the time taken will scale linearly with the number of possible routes to be considered in effect). To O(V^2) which would mean that the time taken would start to become exponentially more as the number of vertices (stars) to be considered increases.. My guess is that the algorithm used by FDev is not O(E) since it does not seem to scale linearly.. It might be that it isn't possible for them to use that one..

I think the main algorithm is pretty speedy - it's A* - but it runs into other issues. This is either due to having to generate all the stars in the first place so it knows what options it has, or due to doing an extra step for fuel optimisation; our theory is that whatever they use for the "extra step" - if there is one - is O(scary) when it comes to the star densities found in the core.

 

[lionhead]

That's basically what the equation does, except it tries to take into account that it won't be an exact multiple because the hops aren't (quite) all in a straight line - you're bouncing between stars either side of the straight line, which effectively loses you distance.
With that said, there's nothing to stop the calculation from ending up exactly one jump-range below that straight-line distance... Although in a straight-line you could do 830Ly in 20 jumps (assuming 41.5Ly range), it could just as easily be that you can do 830Ly in 21 jumps wherever you are... That will always happen quite a bit on the way into the core; initially you might do the same distance in 23 jumps, then 22 and finally 21... The "magic number" for a given jump count will rise constantly as the star density gets higher.

What i'm saying is that with the multiplication table the line will become as straight as it can get. You don't have to look at the amount of jumps at all if you do it by the multiplaction table, it will automatically have a limited amonut of jumps it can do. Its about limiting the jump options for the calculator and a more accurate route length does that good enough(again, i haven't tested it out thoroughly yet as i'm not at the core atm)

 

[Omgzzwtf]

I can't rep you enough for this post, you saved me SOOOOOOOO much trouble waiting on routes, lol. I love tooling around in and near the core, and it's always taken me forever between routes, so thanks for making it easier. I just wish I could send you cookies or something, because rep just isn't enough.

 

[Another Nephron]

I've been having a spot of bother trying to use this application. I'm currently just under 11K LY from Sag A* and already having problems plotting. I'm on the Xbox One version of ED though, so not sure if that isn't helping. I plugged in the numbers to the highest accuracy it would let me, and it suggested that my 49.15 LY jump range at 11K distance should get me to an optimal plotting range of 956LY. I've been stuck on 97% plotting to a star 955.99LY from my current position for about 20 minutes. Any suggestions?

 

[Esvandiary]

I've been having a spot of bother trying to use this application. I'm currently just under 11K LY from Sag A* and already having problems plotting. I'm on the Xbox One version of ED though, so not sure if that isn't helping. I plugged in the numbers to the highest accuracy it would let me, and it suggested that my 49.15 LY jump range at 11K distance should get me to an optimal plotting range of 956LY. I've been stuck on 97% plotting to a star 955.99LY from my current position for about 20 minutes. Any suggestions?

If you're stuck at 99% it likely means you need to try a little bit lower. The lower the "last" percentage is, the less work it needs to do to make a route - 99% is basically the worst-case scenario, where it can almost plot in one jump fewer, but not quite.

 

[Another Nephron]

Thanks, that tip worked like a charm. Just made it to Sag A*!

 

[Esvandiary]

Thanks, that tip worked like a charm. Just made it to Sag A*!

Hooray... Glad I could help, and congrats on making it!

 

[kiltum]

Here is another calculator, web-only, for all, who cannot install anything.

https://multik.org/ed/

PS No cookies, no logs, no data stealing, no ads. Old pure web page

 

[Alec Turner]

Here is another calculator, web-only, for all, who cannot install anything.

Nice! One minor criticism, I was confused by the "Distance from Sagg A*, LY (XX*1000)" box. You're supposed to enter the number of kly right? (not the number of ly - when I first tried it I put in 1010 and got a negative number as my best distance. Suggest you label the box as "Distance from Sagg A* in KLY (LY/1000)" (maybe even without the bit in brackets). Or perhaps have examples in the brackets ...

Your max jump range in LY (e.g. 33.18)
Distance from Sag A* in KLY (e.g. 5.37)

 

[kiltum]

Nice! One minor criticism, I was confused by the "Distance from Sagg A*, LY (XX*1000)" box. You're supposed to enter the number of kly right? (not the number of ly - when I first tried it I put in 1010 and got a negative number as my best distance. Suggest you label the box as "Distance from Sagg A* in KLY (LY/1000)" (maybe even without the bit in brackets). Or perhaps have examples in the brackets ...

Your max jump range in LY (e.g. 33.18)
Distance from Sag A* in KLY (e.g. 5.37)

Absolutely not a problem. Just copypasted your proposal

 

[schurem]

huh. I used the above calculator (its result were satisfyingly close to my own results) but the route planner still completely choked up. The game becomes almost entirely unresponsive, which is seriously BAD. BAD fdev! never ever shut your user out because your code is too busy running in circles! If i kill the map with a keypress it should abort routing, not keep plugging all cpu cores with its fruitless efforts!

God this is $#&@#(ing annoying. ANNOYING!

[/venting mode]

 

[goemon]

huh. I used the above calculator (its result were satisfyingly close to my own results) but the route planner still completely choked up. The game becomes almost entirely unresponsive, which is seriously BAD. BAD fdev! never ever shut your user out because your code is too busy running in circles! If i kill the map with a keypress it should abort routing, not keep plugging all cpu cores with its fruitless efforts!

God this is $#&@#(ing annoying. ANNOYING!

[/venting mode]

i had zero problems with calculated range till ~1500 ly from sag* (i didn't wanted to go there, but to cross from -2900 below to the great annihilator). than i had to give up with routeplotting ~25 minutes per plot. it's my third time at the core, first time with an engineered ship - my assumption is, that jumpranges above 40 ly really make the routeplotter fail for too many options.

next trip to the core, i will take a modest 30 ly jumprange ship again.

 

[Esvandiary]

Just in case it helps... Near the end of the calculation I've found it's often best to replace the (D * 2) with ((D + 1) * 2)

This makes the estimate slightly more conservative... At worst it makes the number slightly too low when it was fine, which isn't a big deal. But at best it takes what was previously a slightly too high estimate (which is the worst possible scenario) and makes it just right.

So in summary for those having problems: if it's still not working, try a few light years lower.

 

[Major Klutz]

No easy way that I can see to cancel a route plot now, BUT ...
I find that if the route plotter is stuck at 98 or 99%, I can select another star, a couple of light years closer and try again. Plotting to another destination seems to cancel the first one, and I can usually get a route plotted quickly after two or three tries.

At present, I'm still ~10Kly from Sag A with a 32.8ly jump range. I'm sure it will get worse as I get closer.
The stars are getting too dense to even see through, so I've started filtering out all but one or two star classes, so I can see better to pick a star to plot to.