PMC Elite Dangerous - TradeDangerous


TradeDangerous (TD) is the greatest trading tool for Elite Dangerous simply because it has the ability to return the BEST trading profit collected from ALL stations! which no other tool does (others ask you from which system you want to search best profits).

Are you tired of wondering where the best REALLY the best profits are? Well TD has the answer for you.

TD also gives you the ability to search for very large loops, for example we have tested it several times with 120 hop loop and it works great.


python3 import --plug=maddavo --opt=syscsv --opt=stncsv -v
python3 run --cr 10000000 --cap 532 --ly 12.02 -vvv --pad l --ls-max 1500 --avoid alioth
python3 import import.prices
python3 update -T --editor=nano
python3 station --add sys/stat --ls 0 --bm y --pad l
python3 station --update sys/stat --ls 0 --bm y --pad l
python3 run --cr 10000000 --cap 532 --ly 12.02 -vvv --pad l --fr ltt377 --via g26847/arch --to ltt377 --hops 3
python3 local --ly 27 -v aulin|more

Landing --pad-size sml?. Small, Medium, Large and ? is unknown (doh). So for type-9's do "--pad l"

python3 run --from sol --start-jumps 3 --hops 2
python3 run --from sol -s3 --hops 2

--routes 10. Added a "--ls-max" option to "run" so you can set a hard limit on how far you'll fly. This lets you say "I want to go from somewhere within a couple of jumps of sol to somewhere in the vicinity of lave": run ... --from sol --start-jumps 2 --end-jumps 5 ...
or run ... --from sol --start 2 --end 5 ...
or run ... --from sol -s 2 -e 5 ...
or fly to somewhere near Anlave that has a black market: run .. --to anlave --end-jumps 4 --black-market run .. --to anlave -e 4 -bm
python3 station --add --system <system_name>/<station_name> --ls-from-star 0 --bm ? --pad-size m
python3 station --add --system Lansbury --ls-from-star 0 --bm ? --pad-size l Landis Settlement
python3 station --add --system Lansbury --ls-from-star 0 --bm ? --pad-size l Thomson Orbital
python3 station --add --system Lansbury --ls-from-star 0 --bm ? --pad-size m Henson Laboratory
$ station --add "guiwande/aikin horizons"
or if you know the ls-from star, the pad size and whether the station has a black market:
$ station --add "guiwande/aikin horizons" --ls=3948 --pad=l --bm=y

"does it only update it to the SQL .db file like it says, or to Station.csv as well?", only in the local station, you'll need to do a " export --table Station" when you're done. Or ... add a blank line at the end of the file and then the following code (which is not indented, no spaces or tabs infront of it):

import csvexport
csvexport.exportTableToFile(tdb, tdb.tdenv, "Station")
print("Rebuilt Station.csv")

Data is merged into the master Station.csv file automatically. So we all add info to our Station.csv files, upload them, and then get a new master file. It usually takes 2 minutes to merge data into the database and generate a new set of master files available for download.

If a station needs to be deleted, this can be achieved by setting the distance to -1 in the Station.csv when it is uploaded. That will delete the station from the database and flag it as deleted so that anyone else sending the station again will NOT recreate the station.

Yep, literally. TD barfs with a -1 distance. Set to -1 to delete. Upload. Wait. Download/import. Continue. I tend to do deletes at the end of a session so I don't have to wait.

python3 run --cr 2556705 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr BD024304/Durrance --insurance 3611881
python3 run --cr 2934671 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr BD024304/Durrance
python3 run --cr 594348 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr BD024304/Bean --insurance 3611881
python3 run --cr 5322580 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr SUESSETANI/Gutierre --insurance 3611881 --to BD024304/Durrance --hops 1
python3 run --cr 9267358 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr SUESSETANI/Gutierre
python3 run --cr 5322580 --cap 532 --ly 12.02 -vvv --pad l --ls-max 1500 --avoid alioth --fr SUESSETANI/Gutierre --insurance 3611881 --to BD024304/Durrance --hops 1
python3 run --cr 2837250 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr LOUGUALA/Mcmullen --to BD024304 --hops 1
python3 run --cr 2934671 --cap 532 --ly 12.02 -vvv --pad l --avoid alioth --fr BD024304/Durrance --hops 12 uses requests module for CSV downloads but older method for .prices files.

Script to leech and rename system/station csv files:

cd tradedangerous/data
rm System.csv
rm Station.csv
mv station.asp Station.csv
cd ..
python3.4 import --plug=maddavo -O usefull import --plug=maddavo -O csvs import --plug=maddavo -O csvs,csvonly import --plug=maddavo -O usefull import --plug=maddavo -O use2d import --plug=maddavo -O use3h

- Added "--stock" option to set minimum stock level required. CAVEAT: It will ignore any stations that have "?" as their listed quantity. local Ross209 --ly 20 --stations -vv local Ross209 --ly 20 --stations -vv --pad ?


Maddavo's Market Share

You can upload a big Station.csv from your TD data directory, OR a small <any-name>.csv - it doesn't matter. All that is REQUIRED is the first line that has the Station.csv schema. That's how it knows it is a Station.csv-format file.

Merging Data
Any new stations are added IF the System exists in our System.csv. In theory, we have been given a list of all the systems that have stations, this weeds out typos.

Any existing stations are updated if the ls_from_star, blackmarket or max_pad_size change from default values. If ls_from_star is within 10Ls or 1% then it is ignored.

Any other conflicting data is NOT merged into the database - it is flagged for checking. I am writing a crowdsourcing 'fix stations' page where cmdrs can help check stations and choose which data is correct.

Station Distance - ls_from_star values. Some points about station distance:

The ls_from_star value changes. The game is real-time and orbiting objects in a system move. Although they move slowly, they DO move. If you have a station orbiting a planet then the ls_from_star will oscillate around an average value (the planet's orbital distance). If you have a station orbiting a moon orbiting a planet, then the ls_from_star will oscillate around the moon's oscillation around an average value (also the planet's orbital distance). Things get even more complicated when binary or n-ary planets or stars are involved.

It IS very possible to have stations in a system with the same ls_from_star values. If they are orbiting the same body, then their average ls_from_star will be the same. But also if they are orbiting a moon or planet that is orbiting another body (eg: <star> B, C or D) then their average ls_from_star will also be the same. eg: in SOL: Abraham Lincoln, M.Gorbechev, Li Qing Jao all orbit Earth so they have the same ls_from_star value. Earth's orbit is 1AU so their ls_from_value is 499 (or close to it). Galileo orbits the moon, the moon orbits earth, so Galileo's ls_from_star value is also 499. In our Station.csv the values are 505-506, fair enough.

The System View can be used to get the distance in many cases. eg: If there is a station orbiting a planet orbiting an A star then select the planet and look at the orbit semi-major axis value. The elliptical orbit is generally close to a circle and this can be used. The value is in AU (Astronomical Units). 1 AU = 499Ls . So multiply this value by 499 and you have the ls_from_star. If there are binary (or n-ary) stars in the system and the station is orbiting B or above, then you can't use the System View. You have to know the distance of the n star from the A star which isn't shown in the System View - you have to visit the system. So once you visit the system, you may as well just get the distance of the station from the nav panel.

The System View cannot be used if the station is part of the orbital hierarchy of a binary or n-ary planet or part of the orbital heirarchy of a binary or n-ary star B or higher. This is because the reported semi-major axis value is for the orbit of the partner body - it does not show the orbit of the collective COG to the parent body (frustrating).

When you jump into a system, you jump in at the A star. This is the one with the Nav Beacon. But you jump in near it, not in the centre of it. So if you jump in and 'stop' (still going 30m/s) and look at the nav panel then potentially you could be on the near side or the far side of the star from the station you're looking at. This introduces another oscillation into the ls_from_star value if you measure it with the nav panel in this way.

Some people land at the station, then look at the nav panel and choose the distance to the Nav Beacon. It's probably better to choose the A star.

So basically if we all measure a station's ls_from_star value by various means and we're within about 10Ls or 1% of each other then I think that's good enough. It's certainly good enough for the purposes for which we use it in TD.

April 2015 Notes


I've just landed 1.8.2 which adds "--loop-int", this lets you specify that you don't want to go back to the same station in less than X hops, e.g. run synteini/lager --pad L --hops 6 --sum --ls-max 4000 --stock 10000 --ly=42 -li=2

will find routes that requires at least 2 hops between returns to a given station

A->B->A->B <- not allowed
A->B->C->A <- allowed

--shorten requires "--to"; it does the same thing that "--to" does, but it will allow routes that reach the destination in less than --hops jumps to be considered and at the end of the route calculations it will compare routes based on their average Gain Per Ton (gpt).

This will get stuck on loops if there's a really good loop between you and your destination (I just had this happen on the way to Shinrarta, someone had input a really bad price for Gold that produced >3000cr/ton profits, I shoulda used --max-gpt, duh).

Another useful thing to do - occasionally - "--limit". If you've got 500 cargo capacity, try using "--limit 450" sometimes and let TD suggest some extra stuff to help you stir up sales a bit.

Why some stations have some old prices? (obsolete in 2017 when we have EDMC/EDDN etc tools).

It comes down to this: The OCR tools provide incomplete data, so we had to break the import model to support them. Along with people who contribute by submitting individual line-item updates, the data set as a whole acquires certain properties. The data we have for most stations is "gossip", we have a particular snapshot value from a point in time and no way to tell what the lack of updates means.

This results in spreads of prices at stations, and TD's still a little inconsistent about how it represents this. In particular, sometimes a station will wind up with a single line item that's ancient because the only people who have visited the station in a while are using an OCR tool, and the OCR tools don't know whether the item is gone or you didn't take a screenshot of them, so the OCR tools only send updates, not deletes...

The station then gets a bad rep for having "old" data, and people avoid it, missing out on great prices.

rebuild database?: build -f