The Route planner discussion thread
- Thread starter GunnyHighway
- Start date
Avago Earo
Banned
Nice One. Very handy.
Extremely useful! Thanks!
Hi, guys, just pushed a critical update. If you were getting error 500 often this was probably it!
- Fixed a critical error where users were getting error 500 when values were illegal.
Info on the web:
p.s: just redeployed... forgot to change a variable and it wouldn't accept distances >200 lol sorry for that
- Fixed a critical error where users were getting error 500 when values were illegal.
Info on the web:
p.s: just redeployed... forgot to change a variable and it wouldn't accept distances >200 lol sorry for that
Last edited:
Feature Suggestion: would it be possible to leave the selected systems in input fields after calculating und displaying the route? It would then be possible to toggle between "Shortest Route" and "Economic Route" instead of inputting them again.
And thanks for your tool, much appreciated!
And thanks for your tool, much appreciated!
Good news 
good effort, but my first attempt got nothing ! 100 LY distance. will look at it in future to see improvements
- - - - - Additional Content Posted / Auto Merge - - - - -
2nd attempt was better
You need to show up a message if a route cannot be calculated(I increased my jump range) , will use it for long journeys
- - - - - Additional Content Posted / Auto Merge - - - - -
2nd attempt was better
You need to show up a message if a route cannot be calculated(I increased my jump range) , will use it for long journeys
Improvements unfortunately is just more systems in the database, right now only 1/5-1/7 of the systems in the "populated bubble" (100-150k according to FD) are in the database, that means in some circumstances you won't get neighbours for a node with your current range, it's not a bug. Can't do much about it, but it will 'fix itself' when the database gets more complete.
But if you got >12 ly jump range you should get a route most of the times unless is an isolated system or a very long route (then the chances of getting an impossible jump increases, specially if you got low jump range).
Yes it will happen soon(tm)
right now if there is not a route you should get a table with just your origin system.Improvements unfortunately is just more systems in the database, right now only 1/5-1/7 of the systems in the "populated bubble" (100-150k according to FD) are in the database, that means in some circumstances you won't get neighbours for a node with your current range, it's not a bug. Can't do much about it, but it will 'fix itself' when the database gets more complete.
But if you got >12 ly jump range you should get a route most of the times unless is an isolated system or a very long route (then the chances of getting an impossible jump increases, specially if you got low jump range).
Yes it will happen soon(tm)
ty
and my 2nd post above ?
(re partial LY numbers)Looks like a good start, but here are some comments:
- After the search, please keep the system fields filled out with the previous search so it's easy to do a new search with modified parameters.
- The results look a bit suspicious compared to, say, http://tajti.co/elite/map/. Set the jump range to 16Ly on both, set http://tajti.co/elite/map/ to have fuel of 32t and 2.45 for the exponent. Do the same search and the results are completely different. Your result seems to be more jumps.
- After the search, please keep the system fields filled out with the previous search so it's easy to do a new search with modified parameters.
- The results look a bit suspicious compared to, say, http://tajti.co/elite/map/. Set the jump range to 16Ly on both, set http://tajti.co/elite/map/ to have fuel of 32t and 2.45 for the exponent. Do the same search and the results are completely different. Your result seems to be more jumps.
ty
and my 2nd post above ?
yes shouldn't be much of a problem, the reason I haven't done it yet is because validation is just easier with integers (can be done with a simple html tag on the client), but it shouldn't be very difficult to do. Added to the backlog. I'll be pushing those small updates ASAP, the server is in hot deployment mode so shouldn't disrupt service (hopefully). keep suggestions coming
Some obvious ones which are in the 'to do' list: partial routes when destination cannot be reached, taking fuel into consideration, routes with multiple stops... all those are needed for more complicated planning tools so they will come... at some point
yeah that means you cannot reach it with that range. I'm goign to update it to show a warning in the next hours.
-First suggestion is on the backlog already.
- About second... would take a bit of time to explain why this could happen. I'll try to post a longer explanation later on, the shorter one is: right now with the current implementation I cannot guarantee you will always get the absolute shortest route (this is because how each dev makes their heuristic algorithms that you will get different results, there is no other way to approach this because finding the REAL with 100% confidence degree shortest route is an NP Complete problem, which means amongst other things in layman terms it gets more expensive to resolve as you increase the number of operations (exponentially).
The good news is the algorithm is scalable and can cover very long distances. The difference should never be abysmal (maybe 1 or 2 more hops?). I can try to improve it, and may in the future, but this will take some work so is low priority (it works 'good enough' and most of the times it will give the shortest route).
Last edited:
Updated it with a couple minor things:
1) Now it will remember your last selection & range (it won't use cookies though, so if you close your browse it won't remember it, is just from request to request), this is good for the server too as it will get less hammered by partial queries, so a win for everyone!
2) Now there are warnings for both cases: a) no route found; b) distance between systems two high. No more 'error 500' or enigmatic results!
Next which shouldn't take long is accepting float numbers as valid inputs for range.
1) Now it will remember your last selection & range (it won't use cookies though, so if you close your browse it won't remember it, is just from request to request), this is good for the server too as it will get less hammered by partial queries, so a win for everyone!
2) Now there are warnings for both cases: a) no route found; b) distance between systems two high. No more 'error 500' or enigmatic results!
Next which shouldn't take long is accepting float numbers as valid inputs for range.
Last edited: