Routing tools for sparse regions?

A quick query, as my search skills are failing me here: what tools currently exist to find routes in sparse regions (i.e. where synth boosts will be needed)?

The impression I get is that there isn't all that much interest in such tools nowadays, as jump ranges are so long that there aren't many places where the in-game route plotter can't do the job. The much more common case of finding waypoints for neutron jumping or POIs for exploration is of course well served by existing web tools, but they all assume that the in-game router can get you to the waypoints. In my situation, I'm attempting to reach some very distant points and I'm curious if there is any tool that can tell me if I'll be able to make it there at all with my jump range. For instance, my current destination is the very tip of the Sag-Car arm west of Beagle. I can see in EDSM that it's had a few visitors, and I even found the flight log of a player that had been there. However following the route they took wouldn't be very practical: that player's ship has about 20 LY on mine in base range, so I'd be burning a lot of basic synth materials to follow it directly, and the route included some jumps that are longer than even the premium-boosted range of my ship.

So in principle it wouldn't be hard to download the EDSM catalog for the region - it's sparse so there aren't that many stars to contend with - and write a jumponium-aware A* pathfinder. (The one in EDTS isn't jumponium aware AFACT.) But I'm wondering if something like that already exists and is currently maintained and in good working order?
 
EDSM doesn't store region against systems within it's database (I assume you mean region like "The Void" or "Hawkings Gap" rather than sector ?).
 
EDSM doesn't store region against systems within it's database (I assume you mean region like "The Void" or "Hawkings Gap" rather than sector ?).
No I meant "catalog for the region" as shorthand for "use the API to download the 200 LY cubes corresponding to my area of interest".
 
How about that one?
Albeit you have to download the database and run it for yourself, no fancy pancy user interface. But it works.And even though it is not considering neutron jumps (which doesn't matter that much in low star density regions) it will get you the most jumponium efficient route … with system reported to EDSM that is.
 
Last edited:
How about that one?
Albeit you have to download the database and run it for yourself, no fancy pancy user interface. But it works.And even though it is not considering neutron jumps (which doesn't matter that much in low star density regions) it will get you the most jumponium efficient route … with system reported to EDSM that is.
Intriguing, that certainly seems worth a try! And you wrote it in Python to boot, hooray - it's like a second language to me, so you'll have to forgive me if I tinker with it a bit.
 
It's published under the GPL v3. So it's your fundamental right to do whatever you want with it … with the caveat that, if you decide to publish your changes based on my software, you have to put everything under the the same license again … don't jail my babies ;)

Anwyay, the program is by no means optimized. So if you find a better (faster) way to do things, I would really like to hear some feedback. I mention some problems in the original post. I've also tried to rather write as explicit as possible to make it easier for others to understand it. I guess I often have too many comments.

The original intention with the program was to find a path that uses as little jumponium as possible. That was the "prime directive". And also a reason why I didn't implement Dijkstra's algorithm.

Also, while the program offers an option that uses the EDSM API would I encourage to download the database and use the offline modus. It's faster and I think EDSM has a limit on how many inquires can be made (per second/hour/day?).
 
It's published under the GPL v3. So it's your fundamental right to do whatever you want with it … with the caveat that, if you decide to publish your changes based on my software, you have to put everything under the the same license again … don't jail my babies ;)
Indeed. I've done quite a bit of open source work myself, I'm always pleased to find a project whose author has the forethought to select a time-tested license.

Anwyay, the program is by no means optimized. So if you find a better (faster) way to do things, I would really like to hear some feedback. I mention some problems in the original post. I've also tried to rather write as explicit as possible to make it easier for others to understand it. I guess I often have too many comments.
No promises, but I'll certainly be in touch if I am suitably inspired. Okay to submit issues/PRs through your Github repo?

The original intention with the program was to find a path that uses as little jumponium as possible. That was the "prime directive". And also a reason why I didn't implement Dijkstra's algorithm.
I'm still trying to puzzle out what exactly you have done. It seems conceptually similar to Dijkstra, in that there appears to be a breadth-first search of the node graph taking place, except that you're iterating in order over increasingly expensive jump boosts. I suspect it could go faster using a cost heuristic like in A*, although possibly you've already gained most of the benefit by constraining the search to a tube around the straight-line path. Dunno, like I said, I might play with it.
 
I suggest to check if you can get there without using any tools. The reason is tools can only work with already visited systems and there may be some routes with more adequate jumps for your ship. I use the "orange hats" and tags to make my own routes in the sparse zones.

BTW, what is your jump range? If you want to reach a system in the very edge of the galaxy, I garantee you that 67 ly is enough for any system but a dozen of them.
 
You are right, the path is more of an indication as a "no other way" option. But a path through the known systems is an indication if a system is at least reachable with a given jumprange and a given amount of jumponium. This allows to plan ahead to be able to certainly make it there and back and any undiscovered systems on the way are a nice help :)
 
Back
Top Bottom