This tool is an alternative to the in-game route optimization function. The in-game function cannot handle large lists of waypoints due to processing time. This tool has an adjustable level of recurrence which allows you to sacrifice accuracy for speed for large lists of waypoints. You can also use the tool to process long lists of waypoints in the background while you continue to play the game.
To use the program:
Choose either shortest, secure or insecure for your route using the radio buttons. If you do not, shortest is used by default.
Choose the number of cycles. Higher values will allow the script to consider more possible routes. If the value is high enough for the given number of waypoints, all possible routes will be considered and the result will be optimal. Lower values will take less time to process but the end result will be sub-optimal. A high number of cycles for a long list of waypoints can take an unreasonable amount of time to process.
Enter your origin and first waypoint. Then press the enter key.
Enter all remaining waypoints one by one into the destination field, pressing the enter key after each one.
If you would like to use a fixed endpoint, click the check-box and enter the name of the system you would like to use for the fixed endpoint, then press the enter key.
Click the “optimize” button.
The script will run, yielding an effectively short route for the given waypoints. When multiple cycles are used, all possible routes are compared and the shortest is returned.
Compare the number of jumps displayed immediately after clicking the optimize button to the number provided after the process has completed to verify improvement.
Will it always give the same route if I set a destination from Kaaputenen to Josameto and shortest, or does it work like the EVE AP and also give me 3 different routes with the same number of jumps every time?
From Kaaputenen to Josameto, the script will get whatever the ESI returns.[Kaaputenen,Inaro,Sirseshin,Tuuriainas,Geras,Nomaa,Poinen,Josameto].
This script is for improving the total route for many waypoints (over 12). The individual systems between one waypoint and another are not displayed. What it does is take all of the waypoints you enter, in whatever order you provide them and attempt to rearrange them in a way that reduces the overall number of jumps.
that would be somewhat progress, although it still is not the shortest. The shortest by AU is arguably Kaapu, Inaro, Sirppala, Urlen, Perimeter, Jita, New Cal, Josameto because the warps are significantly shorter than on the Poinen route.
There is no reason to be so rude and angry. I have done my best to describe exactly what the script does and what it is capable of. Coming here, swearing and insulting me over semantics is ridiculous.
Nowhere in the OP here do I say that the script “optimizes” the route and I did that specifically based on our conversation in the other thread, yet you have shown up here and attacked me anyway.
The only use of the word “optimize” is that the script itself is called “route_optimizer”. It’s an alternative to the “optimize” button in the game because that button does not work for long lists of waypoints.
read the title of this post again. And tell me you never said it “optimizes” thing.
It’s not. The ig button actually optimizes thing. Your script does not. That’s why the ig button takes so long, and you script does not.
Affirming your script makes the same thing as a program that actually optimizes is ridiculous. Does not prevent you from doing it.
And somebody who reads your post will thus assume your script DOES make a route optimization, because you called it that way, and thus will assume CCP devs are stupid to not have embedded that function in the game.
Because you lied, when calling your script route_optimizer.
That’s a good point. Those huge systems that can take two warps to get across are a pain. I guess the ESI does not take that into consideration when it gives you a route.
If you don’t like the name of the script, you can change it. A link to the source code is in the OP. You can even create a new thread, releasing the program under a different name. You can even include a lengthy description of how stupid and terrible I am. If that makes you feel better, I am completely on-board.
The script was created in response to this question: Why only 10 to 12 waypoints for optimization? The pupose of it is related to the “optimize” button in the game. I’m sorry if the use of the word “optimize” offends you in some way, but you can clearly see why the word was used. It’s not an attempt to claim that i’ve achieved something impossible and I think that’s pretty obvious if you read the OP here.
Yeah, in attempt to claim your script does optimize something.
Which you believed was true. But actually it’s false. So now you know why you were wrong, and why you must not call your script “optimizer”.
Yet you keep calling this script “optimizer”. Which it is not and you know why.
So you are lying.
Telling me what I can do is not the same thing as correcting your errors. I don’t care what I can do. I tell you that you are lying to people and that you must correct your errors.
What if I were to change the name to “path_finder” or something similar? Would you feel better? I really don’t care what it’s called. I should have time later today to do something like that.
The ESI works on the internal static list of system-to-system routes.
IT’s very difficult to make a correct route optimizer that takes into account the ship caracteristic, because it actually needs to make a new dynamic distance metric : the distance in AU is increased by a given number for every warp started, and every gate passed. Those number depends on the ship align time and the warp speed. for example a 2s-align 30AU/s has an additional cost of 300 AU per gate (10s)and 390 AU (13s)per warp.
Meanwhile a 1.5 AU/s, 30s align ship has an additional cost of 15AU per gate (10s) and 130 AU (87s) per warp.
THEN you also need to have the correct list of gate-to-gate (g2g) distances and then gate-to-station ones. Plus the align properties of the original station, to compute the aditional time(/distance) to align.
eg if I go from jita IV 4 to perimeter I need to compute the angle from jita IV 4 to the perimeter gate, the distance, then the distance from the perimeter gate to Jita to the station I want to go to. Total distance I add the one warp from jita IUV then one warp from the gate in perimeter.
what about greedy_rerouter ? Or give it a funny name, that’s what people do anyhow. It’s a script, that does not optimize, but it’s “gudenoug” ? Call it “commercial_buddy”
An adjustable level of recurrence has been added to the script. This is now explained in the OP as you can see in the quote below. Simply put, the number of cycles affects the processing time and quality of the resulting route.
DETAILS:
When the script comes across a waypoint where all of the remaining waypoints are the same distance away, it will choose the first one available and save that route in an array.
On the next cycle, it will try a different route. For each following cycle, another route will be attempted. This continues until all possible routes have been considered.
If the number of cycles exceeds the number needed to find every possible route, the script will continue running until the remaining cycles are complete but you will start seeing messages such as “Best possible route already found for this waypoint”.
Once all of the cycles have completed, all of the routes created by these cycles are compared to find which one is the shortest. This is the result returned by the script. If you have a large number of waypoints and the process cannot be completed in a reasonable amount of time, you can reduce the number of cycles and obtain a sub-optimal result.
A large number of cycles with a large number of waypoints will likely take an unrealistic amount of time to process.
Some bugs with route comparisons were fixed today. For anyone using the program, you will need to download it again to get the latest version. You will notice new messages displayed during comparisons showing how the best route is selected.
If anyone read the previous discussion about this script and were perhaps wondering what all the commotion was about:
After the recent updates described above, the script does in fact “optimize” routes according to the definition of the word I was pressured to adhere to.
In order to process large lists of waypoints in a reasonable time frame, you can reduce the number of cycles. This will produce a route that is not the absolute most perfect route and does therefore not fit this definition of the word “optimize”.
This is how the script worked before these updates. The route will still be improved if you decrease the number of cycles, it will just not be the absolute most perfect result. What happens in this situation is best described here.
