You have a bunch of trading missions and want to finish them asap? However, several factions on different stations want you to source and return various commodities? You also need to deliver stuff to different stations? You would prefer picking up commodities at stations where you have to go to anyway? At the same time you want to visit as few stations as possible for commodities that can't be found at mission locations?
The awesome EDDB.io has a lot of the information needed for traders. However, you have to look up what you look for manually. If you have many missions that means many manual comparisons have to be done to get the information you want. After all information is collected a route that requires visiting as few stations as possible needs to be figured out. The latter also has to be done manually and may take a lot of time.
Many trading tools are available for ED but I couldn't find one that optimizes missions. Hence, I wrote one myself and you can find it on GitHub under a GPL v3 license.
What the program does is the following.
If no local copy of the necessary files from EDDB.io are present (or if the local copy is too old) it downloads them. This is the largest disadvantage of this program since these files can be up to a day old.
Afterwards it builds a smaller database with the given parameters that contains just "relevant" stations.
These two processes need ca. half a minute to be completed. Thus this smaller database is saved locally so that no further time is wasted on this for subsequent runs of the program.
The database needs to be rebuild if the parameters change significantly. This however can simply be done by calling the program with a parameter that says so.
The origin location (station and system) and mission details (station, system, commodity, quantity) need to be provided by the user in a separate file.
For the (small) database to be correct, the laden jumprange and the required padsize need to be provided as parameters when the program is called.
Dito, for the maximum number of jumps that are allowed to get a commodity and the maximum distance to arrival a station can have to be considered relevant.
Finally, the minimum number that must be available of any commodity at a given station needs to be stated by the user.
For all these default values exist.
Now we have a database that contains just relevant stations.
The program than figures out the mission stations that one needs to fly to. These are the stations for source and return missions and the stations for delivery missions. It then checks if any of the mission commodities can be found there. Why flying somewhere else if it is available at a location where I have to go anyway?
Afterwards stations are found for all commodities that can NOT be bought at mission stations.
For this three rules apply:
1.: If two (or more) commodities can be found at one station, this station is to be used.
2.: Stations that are closer to the point of entry into a system are to be used over stations that are further away.
3.: Orbiting stations are always preferred over planetary stations. In this case rule 2 does not apply even if the planetary station is much closer.
The first rule "catches" the fact that flying to a station, docking and undocking takes much more time than jumping to another system. Thus, the more commodities I can get at a station the better. This has of course limitations, and that is what the maximum allowed jumps parameter (which translates to the maximum distance from the origin location) is for.
The third rule "catches" that getting down to a planet takes much more time than docking at an orbiting station. Dito when leaving. The limitations of this is the reason why the maximum allowed distance from arrival exists.
Now we know which stations I actually have to fly to to fullfil all mission requirements.
Now the program permutes the order of stations. For each permutation it checks if delivering goods and buying from the stations in the given order will lead to a route that does not require visiting a station twice. Or if that is not possible, that the least amount of stations need to be revisited.
This process takes the available (and changing) cargo space into account.
The first route that is found is returned to not go through all permutations because that needs a lot of time.
This however is NOT necessarily the shortest route (regarding distance), nor the most profitable one (regarding money).
Because time was here considered as most important and above I wrote what is most time consuming. Since a maximum distance from the origin is given I don't think that significantly shorter routes can be found. And money? Is anybody doing missions really for the money? I do them so that I get somewhat efficiently engineering materials while it still feels like playing the game und not grinding.
One last comment. Permutation problems grow factorial. It can take A LOT of time if the program needs to go through all of the permutations.
9! is approx. 400,000. In the worst case the program needs to go through all possible routes and it would need ca. 5 minutes. I consider this bearable.
With just one location more to visit the time to calculate all possible routes becomes UNbearable. However, permutations are orders of locations which are NOT too different from one permutation to the next since just the position of two elements are switched. Hence, if the first permutation is a worst case the computations will take very much time. Also, radical changes in the order take place just over many permutations. This however can be considered as randomizing the order of the elements in a list of locations.
Thus, for ten or more locations I will NOT take the risk of running the program for very long but I rather do this -- randomizing the order of locations to be visited. In this case the order of locations is shuffled 400,023 times and than it is checked which one is the best.
Yes, that does certainly NOT explore the whole space of possible routes. But since that would take so much time I wouldn't have done that anyway. Yes, that may lead to checking a possible route twice. So what? the chances for that are really slim and if it happens a couple of times I can live with it. But it is also very likely that I hit a route that is good enough.
More details on how to work with the program can be found in description of the GitHub repository.
The program is written in python 3 and extensively commented.
It was tested on a Debian system and I really don't know if it will work in a proprietary OS.
If it doesn't the most likely point of failure is the default parameter for the file(s) location. I haven't tested that and I don't care. But Hoorah! the source code is published under the GPL v3 and thus you can fix that yourself
Fly safe commanders (and do trading missions efficient)
schlowi123
The awesome EDDB.io has a lot of the information needed for traders. However, you have to look up what you look for manually. If you have many missions that means many manual comparisons have to be done to get the information you want. After all information is collected a route that requires visiting as few stations as possible needs to be figured out. The latter also has to be done manually and may take a lot of time.
Many trading tools are available for ED but I couldn't find one that optimizes missions. Hence, I wrote one myself and you can find it on GitHub under a GPL v3 license.
What the program does is the following.
If no local copy of the necessary files from EDDB.io are present (or if the local copy is too old) it downloads them. This is the largest disadvantage of this program since these files can be up to a day old.
Afterwards it builds a smaller database with the given parameters that contains just "relevant" stations.
These two processes need ca. half a minute to be completed. Thus this smaller database is saved locally so that no further time is wasted on this for subsequent runs of the program.
The database needs to be rebuild if the parameters change significantly. This however can simply be done by calling the program with a parameter that says so.
The origin location (station and system) and mission details (station, system, commodity, quantity) need to be provided by the user in a separate file.
For the (small) database to be correct, the laden jumprange and the required padsize need to be provided as parameters when the program is called.
Dito, for the maximum number of jumps that are allowed to get a commodity and the maximum distance to arrival a station can have to be considered relevant.
Finally, the minimum number that must be available of any commodity at a given station needs to be stated by the user.
For all these default values exist.
Now we have a database that contains just relevant stations.
The program than figures out the mission stations that one needs to fly to. These are the stations for source and return missions and the stations for delivery missions. It then checks if any of the mission commodities can be found there. Why flying somewhere else if it is available at a location where I have to go anyway?
Afterwards stations are found for all commodities that can NOT be bought at mission stations.
For this three rules apply:
1.: If two (or more) commodities can be found at one station, this station is to be used.
2.: Stations that are closer to the point of entry into a system are to be used over stations that are further away.
3.: Orbiting stations are always preferred over planetary stations. In this case rule 2 does not apply even if the planetary station is much closer.
The first rule "catches" the fact that flying to a station, docking and undocking takes much more time than jumping to another system. Thus, the more commodities I can get at a station the better. This has of course limitations, and that is what the maximum allowed jumps parameter (which translates to the maximum distance from the origin location) is for.
The third rule "catches" that getting down to a planet takes much more time than docking at an orbiting station. Dito when leaving. The limitations of this is the reason why the maximum allowed distance from arrival exists.
Now we know which stations I actually have to fly to to fullfil all mission requirements.
Now the program permutes the order of stations. For each permutation it checks if delivering goods and buying from the stations in the given order will lead to a route that does not require visiting a station twice. Or if that is not possible, that the least amount of stations need to be revisited.
This process takes the available (and changing) cargo space into account.
The first route that is found is returned to not go through all permutations because that needs a lot of time.
This however is NOT necessarily the shortest route (regarding distance), nor the most profitable one (regarding money).
Because time was here considered as most important and above I wrote what is most time consuming. Since a maximum distance from the origin is given I don't think that significantly shorter routes can be found. And money? Is anybody doing missions really for the money? I do them so that I get somewhat efficiently engineering materials while it still feels like playing the game und not grinding.
One last comment. Permutation problems grow factorial. It can take A LOT of time if the program needs to go through all of the permutations.
9! is approx. 400,000. In the worst case the program needs to go through all possible routes and it would need ca. 5 minutes. I consider this bearable.
With just one location more to visit the time to calculate all possible routes becomes UNbearable. However, permutations are orders of locations which are NOT too different from one permutation to the next since just the position of two elements are switched. Hence, if the first permutation is a worst case the computations will take very much time. Also, radical changes in the order take place just over many permutations. This however can be considered as randomizing the order of the elements in a list of locations.
Thus, for ten or more locations I will NOT take the risk of running the program for very long but I rather do this -- randomizing the order of locations to be visited. In this case the order of locations is shuffled 400,023 times and than it is checked which one is the best.
Yes, that does certainly NOT explore the whole space of possible routes. But since that would take so much time I wouldn't have done that anyway. Yes, that may lead to checking a possible route twice. So what? the chances for that are really slim and if it happens a couple of times I can live with it. But it is also very likely that I hit a route that is good enough.
More details on how to work with the program can be found in description of the GitHub repository.
The program is written in python 3 and extensively commented.
It was tested on a Debian system and I really don't know if it will work in a proprietary OS.
If it doesn't the most likely point of failure is the default parameter for the file(s) location. I haven't tested that and I don't care. But Hoorah! the source code is published under the GPL v3 and thus you can fix that yourself
Fly safe commanders (and do trading missions efficient)
schlowi123
Last edited:
