Wanted to list out some things I ran into that may or may not be issues (could just be error on my part with options):
The --pad-size parameter is documented as taking a variable length string of SML? characters to specify potential options, notably saying to use --pad-size SML? to specify matching anything. This doesn't actually work, it seems to have regressed to want only a single character and reject any additional characters. I.e. you can only do --pad-size S or M, L etc.
The --checklist option seems to be incompatible with --routes N for N greater than 1. I haven't actually looked at the output of a checklist, but it seems a bit odd that it can't print whatever it prints for each route returned, unless it's interactive (documentation didn't make it clear and I never got around to trying it with less routes).
The --start-jumps and --end-jumps parameters appear to be silently incompatible with --routes, they'll calculate a route and then just return the best route it found, instead of the top N routes.
The --unique and --loop options are mutually exclusive, as per the error output. However giving said error takes an oddly long time for argument parsing, it seems likely the script is already starting to load data before it checks this logic. Assuming trade.py is using argparse these two options, and any other mutually exclusive options, really should just be declared as mutually exclusive argument groups. That way the argument parsing code immediately would catch those errors.
Could trade.py trade get a --loop or --both parameter that makes it output profitable commodities for both sides of the potential transaction, i.e. as if you did trade src dst and trade dst src?
It's sort of wasteful that --age N will process routes fully and then just error out with no routes if it finds nothing within the specified age limit. At least to me it would make sense for it to at least output whatever result is found so far that's next closest to the desired age, at least under the assumption that routes are not being pruned based off of age immediately. I make that guess due to the fact it manages to process beyond the first hop, so it must be processing something (so didn't prune due to age) and yet says no routes found.
The really long part
This brings me to the main thing that prompted me to finally report the above along with this (normally I'd have tried to fix them first). I'm not entirely sure the router is actually optimising correctly. As a test of its behaviour I went to two different stations, compiling .price file information using EDMC along the way, and put the stations into the in-game comparison mode. I also consulted inara to double check the data was being sent / it agreed.
The two stations in question were "7 Andromedae/Papin City" and "Howard/Serling Station". As given by my price files (generate from landing on them) there was, for example, Cobalt at 2740 credits each in Serling Station, and Cobalt being purchased at Papin City for 18,964 credits each. So around a 16k profit per ton one way. For the return journey Papin City sold Basic Medicines at 328 credits each and Serling bought at 913 each, or just under a 600 cr/ton profit. As far as I could tell from the documentation, the --gain-per-ton parameter has no default, presumably allowing arbitrarily low values / 0 profit legs to exist. The two stations are 10.32ly away from each other and have around an aggregate profit of 16.8k cr/ton from a direct path.
Inara confirmed this simple trade route as well. trade.py however... can't find it. I confirmed I had imported the data correctly and trade.py market ... correctly ouputs the right info per commodity. And no matter what permutation of the below command I tried, I couldn't manage to get it to display that trade route as viable. And not because it wasn't the most efficient, the output being given were trade routes with a profit per ton average of 9k or lower involving multiple jumps each. The cost analysis function seems to be a bit iffy in how it's weighing things, or profit legs that are below around 1000 get forcibly rejected (I haven't seen evidence of it making a 0 profit or sub 1k profit route), even if gpt gets set to 0, or it has something to do with supply / demand heuristics as serling station did have relatively low supply (still above 1000 though).
$ ./trade.py run --from "7 andromedae/papin city" --credits 70m --capacity 192 --ly-per 15.39 --routes 3 --hops 3 --to "7 andromedae/papin city" --progress --fc N --age 2 -J -vv --empty-ly 20.24 --via "howard/serling station" --shorten --gpt 0
* Hop 1: .........1 origins
* Hop 2: ........24 origins .. 15,360-792,768cr gain, 80-4,129cr/ton
NOTE: Pruned 23 origins too far from any end stations
* Hop 3: ........39 origins .. 392,064-3,250,752cr gain, 1,021-8,465cr/ton
./trade.py: Error: No routes were found which matched your 'via' selections.
Possible causes:
- No profitable runs or routes meet your criteria,
- Missing Systems or Stations along the route (see "local -vv"),
- Missing price data (see "market -vv" or "update -h"),
I tried without --via (only gets 9k or less), with --loop instead of the --to hack there, with more / less hops, with/without --shorten, with/without --gpt / different values of gpt, with differing values of --age... more or less anything I could think of I tried here. No matter what it seemed incapable of acknowledging this route existed, and considering many of the routes it was finding for --from "7 andromedae/papin city" --loop were outright below 50% the efficiency of this simple hop in credits alone, let alone jumps, it seemed a bit odd how it was unable to find a much larger local maximum.
For what it's worth, trade.py trade ... does correctly output the individual profitable items for the two stations, but I was more interested in testing that trade.py run ... did find my added data + could find a simple maxima like that, it seems unexpected that it can't find it. And I know some of the setting combos I tried were able to output two station loops, so I don't think it's that I had specified it somehow to exclude such trips...
Oh, by the way, this combo triggers an assert:
$ ./trade.py run --from "7 andromedae/papin city" --credits 70m --capacity 192 --ly-per 15.39 --routes 3 --hops 2 --to "7 andromedae/papin city" --progress --fc N --age 2 -J -vv --empty-ly 20.24 --via "howard/serling station" --shorten
* Hop 1: .........1 origins
Traceback (most recent call last):
File "...Trade-Dangerous/./trade.py", line 44, in <module>
cli.main(sys.argv)
File "...Trade-Dangerous/tradedangerous/cli.py", line 66, in main
trade(argv)
File "...Trade-Dangerous/tradedangerous/cli.py", line 121, in trade
results = cmdenv.run(tdb)
^^^^^^^^^^^^^^^
File "...Trade-Dangerous/tradedangerous/commands/commandenv.py", line 84, in run
return self._cmd.run(results, self, tdb)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "...Trade-Dangerous/tradedangerous/commands/run_cmd.py", line 1261, in run
newRoutes = calc.getBestHops(routes, restrictTo = restrictTo)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "...Trade-Dangerous/tradedangerous/tradecalc.py", line 855, in getBestHops
assert not restrictTo or isinstance(restrictTo, set)
AssertionError
Wanted to list out some things I ran into that may or may not be issues (could just be error on my part with options):
--pad-sizeparameter is documented as taking a variable length string ofSML?characters to specify potential options, notably saying to use--pad-size SML?to specify matching anything. This doesn't actually work, it seems to have regressed to want only a single character and reject any additional characters. I.e. you can only do--pad-size Sor M, L etc.--checklistoption seems to be incompatible with--routes Nfor N greater than 1. I haven't actually looked at the output of a checklist, but it seems a bit odd that it can't print whatever it prints for each route returned, unless it's interactive (documentation didn't make it clear and I never got around to trying it with less routes).--start-jumpsand--end-jumpsparameters appear to be silently incompatible with--routes, they'll calculate a route and then just return the best route it found, instead of the topNroutes.--uniqueand--loopoptions are mutually exclusive, as per the error output. However giving said error takes an oddly long time for argument parsing, it seems likely the script is already starting to load data before it checks this logic. Assumingtrade.pyis usingargparsethese two options, and any other mutually exclusive options, really should just be declared as mutually exclusive argument groups. That way the argument parsing code immediately would catch those errors.trade.py tradeget a--loopor--bothparameter that makes it output profitable commodities for both sides of the potential transaction, i.e. as if you didtrade src dstandtrade dst src?--age Nwill process routes fully and then just error out with no routes if it finds nothing within the specified age limit. At least to me it would make sense for it to at least output whatever result is found so far that's next closest to the desired age, at least under the assumption that routes are not being pruned based off of age immediately. I make that guess due to the fact it manages to process beyond the first hop, so it must be processing something (so didn't prune due to age) and yet says no routes found.The really long part
This brings me to the main thing that prompted me to finally report the above along with this (normally I'd have tried to fix them first). I'm not entirely sure the router is actually optimising correctly. As a test of its behaviour I went to two different stations, compiling
.pricefile information usingEDMCalong the way, and put the stations into the in-game comparison mode. I also consulted inara to double check the data was being sent / it agreed.The two stations in question were "7 Andromedae/Papin City" and "Howard/Serling Station". As given by my price files (generate from landing on them) there was, for example, Cobalt at 2740 credits each in Serling Station, and Cobalt being purchased at Papin City for 18,964 credits each. So around a 16k profit per ton one way. For the return journey Papin City sold Basic Medicines at 328 credits each and Serling bought at 913 each, or just under a 600 cr/ton profit. As far as I could tell from the documentation, the
--gain-per-tonparameter has no default, presumably allowing arbitrarily low values / 0 profit legs to exist. The two stations are 10.32ly away from each other and have around an aggregate profit of 16.8k cr/ton from a direct path.Inara confirmed this simple trade route as well.
trade.pyhowever... can't find it. I confirmed I had imported the data correctly andtrade.py market ...correctly ouputs the right info per commodity. And no matter what permutation of the below command I tried, I couldn't manage to get it to display that trade route as viable. And not because it wasn't the most efficient, the output being given were trade routes with a profit per ton average of 9k or lower involving multiple jumps each. The cost analysis function seems to be a bit iffy in how it's weighing things, or profit legs that are below around 1000 get forcibly rejected (I haven't seen evidence of it making a 0 profit or sub 1k profit route), even if gpt gets set to 0, or it has something to do with supply / demand heuristics as serling station did have relatively low supply (still above 1000 though).I tried without
--via(only gets 9k or less), with--loopinstead of the--tohack there, with more / less hops, with/without--shorten, with/without--gpt/ different values ofgpt, with differing values of--age... more or less anything I could think of I tried here. No matter what it seemed incapable of acknowledging this route existed, and considering many of the routes it was finding for--from "7 andromedae/papin city" --loopwere outright below 50% the efficiency of this simple hop in credits alone, let alone jumps, it seemed a bit odd how it was unable to find a much larger local maximum.For what it's worth,
trade.py trade ...does correctly output the individual profitable items for the two stations, but I was more interested in testing thattrade.py run ...did find my added data + could find a simple maxima like that, it seems unexpected that it can't find it. And I know some of the setting combos I tried were able to output two station loops, so I don't think it's that I had specified it somehow to exclude such trips...Oh, by the way, this combo triggers an assert:
Seems to specifically be
--shortenwith--hops 2.