My apologies. I do not understand how to fall back using sourcetree (definitely not a programmer here...) I am trying to figure out how to pull the old one but am having difficulty with it.
That's an "unknown" system to me (can't access the system view) and it's ~330ly away, will take me a while to get there (58 jumps in economy mode). But it's shown as a "Terraforming" economy.
I dropped the pooch, drop-kicked it, tripped over the cat running to recover it, and then screwed it, all because I tried to get clever with git command line/tagging. I locally tagged 6.18.4 and then did a merge on bit bucket and ran into a merge conflict. When the merge resolved, the 6.18.4 somehow had wound up as a non-head. When I was done fixing that, I checked in my perf tuning tweaks to master instead of my branch.
6.18.5 is now up and fixes the "fun" I'd introduced.
Thanks, but I like to travel. Right now I'm gathering data for rares. So I do need to go somewhere far away. This system (Te Kaha) seems like a good place to go. You gave me a new destination, I was heading to Orokudumbla because I liked the name
Yeah, I saw that after I finished my post. Glad you could solve it. Next step is to figure out how to switch back to the master branch, now that kfsone has fixed the bugs.
Just to be clear, when I say unknown system I mean its a system where I haven't visited yet nor it is available by default. Its system map icon is RED in galaxy map, cannot access it. In fact I said "unknown with economy" not unknown economy.
Just to be clear, when I say unknown system I mean its a system where I haven't visited yet nor it is available by default. Its system map icon is RED in galaxy map, cannot access it. In fact I said "unknown with economy" not unknown economy.
Would it make sense to remove the .csv files from being tracked in the repo, as they are often the cause of many conflicts, as we may have updated the files more (or less) recently than you have, Oliver. On the other hand, that may break things of which I am unaware.
--towards option of run sub-command appears to be broken in the current version:
Code:
C:\Users\mk\Documents\Elitedata\tradedangerous>trade.py run --cap 228 --ly 16.9 --cr 50000000 --pad-size L --from Alioth/Irkutsk --towards Sol -vv
Traceback (most recent call last):
File "C:\Users\mk\Documents\Elitedata\tradedangerous\trade.py", line 102, in <module>
main(sys.argv)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\trade.py", line 76, in main
results = cmdenv.run(tdb)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\commands\commandenv.py", line 80, in run
return self._cmd.run(results, self, tdb)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\commands\run_cmd.py", line 1164, in run
newRoutes = calc.getBestHops(routes, restrictTo=restrictTo)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\tradecalc.py", line 872, in getBestHops
for dest in stations:
File "C:\Users\mk\Documents\Elitedata\tradedangerous\tradecalc.py", line 848, in goal_check
for d in stations:
ValueError: generator already executing
No problemo, it works now so all good, thanks for your hard work.
Just to be clear, when I say unknown system I mean its a system where I haven't visited yet nor it is available by default. Its system map icon is RED in galaxy map, cannot access it. In fact I said "unknown with economy" not unknown economy.
Thanks, but I like to travel. Right now I'm gathering data for rares. So I do need to go somewhere far away. This system (Te Kaha) seems like a good place to go. You gave me a new destination, I was heading to Orokudumbla because I liked the name
Oooh, oooh, keep coming to Orokudumbla! We're doing some fun stuff with the background sim there. We managed to get the Purple Central Industries faction in Pand (next nearest system) to expand into Orokudumbla, and now we're busily pushing to drive PCI's influence up and everyone else's influence down until PCI controls the system. (The current controlling faction, the Orokudumbla Rats, are a nasty bunch of pirates; killing their NPCs is a pleasure.) For more information about life on the edge of civilization, check out our forum.
--towards option of run sub-command appears to be broken in the current version:
Code:
C:\Users\mk\Documents\Elitedata\tradedangerous>trade.py run --cap 228 --ly 16.9 --cr 50000000 --pad-size L --from Alioth/Irkutsk --towards Sol -vv
Traceback (most recent call last):
File "C:\Users\mk\Documents\Elitedata\tradedangerous\trade.py", line 102, in <module>
main(sys.argv)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\trade.py", line 76, in main
results = cmdenv.run(tdb)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\commands\commandenv.py", line 80, in run
return self._cmd.run(results, self, tdb)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\commands\run_cmd.py", line 1164, in run
newRoutes = calc.getBestHops(routes, restrictTo=restrictTo)
File "C:\Users\mk\Documents\Elitedata\tradedangerous\tradecalc.py", line 872, in getBestHops
for dest in stations:
File "C:\Users\mk\Documents\Elitedata\tradedangerous\tradecalc.py", line 848, in goal_check
for d in stations:
ValueError: generator already executing
I've got a relatively large changeset incoming in the "development" branch. I've kept it in a branch so that those of you who are comfortable with switching between branches with git might take it for a few runs.
Note: You MUST rebuild the cache after upgrading or reverting (trade.py buildcache -fi), because the database schema has changed.
Testing advice:
1. I would advise doing an import before you upgrade,
2. Check out a few commands before upgrading (if using bash, try history | grep trade.py),
3. Find some slower running "run" commands from your recent history and time them (e.g. if you're using lin/mac/bash: "time trade.py run --from sol --towards waruts --ly 16 --jumps 4 --hops 5 --cr 200k --cap 100 --ls-m=5000 --pad=l --sum --prog"),
4. Try a few of the other commands (see trade --help),
5. You may want to open a second window to test after-upgrade for comparison,
6. After upgrading and rebuilding the cache, retry the same commands without doing any additional imports,
7. If you are using an import other than "maddavo", be aware that import has gone back to it's original heavy-handed approach (when you import a station, all items for it are first deleted). If your import is a merge, use the --merge option to import ("trade.py import --merge somefile.prices)
8. After confirming previously working commands still work, and don't perform worse, try other commands,
9. Try an import,
10. Re-try the established commands, obviously results should vary, but shouldn't break,
v6.19.0 Apr 28 2015
CACHE BUILD REQUIRED (trade.py buildcache -fi)
. (kfsone) "import" command (non-plugin behavior)
- Restored the default behavior over forcefully overwriting existing data
with values from the .prices file and deleting items that aren't listed
in the import.
- Added "--merge-import" option: only imports entries that are newer than
existing local data and only removes entries when there is an explicit
entry for it with 0 prices.
- Changed "--reset" to "--reset-all" because it's a scary command,
. (kfsone) Various commands:
- Consistency:
"demand" refers to what a station will buy,
"supply" refers to what a station is selling,
- Changed several command options from "--stock" to "--supply",
. (kfsone) "market" command:
- Only show the age of items once,
. (kfsone) Performance:
- Re-unified the StationBuying/StationSelling tables into StationItem,
- Added StationBuying and StationSelling views,
- Minor refactor of getTrades to reduce the pathalogical near O(n^2)
behavior it used to match buyers to sellers,
"Database currently holds 18032 Stations in 8467 Systems, 11859 Commodities Markets in 6980 Systems, 634334 Prices"
Looking at the data for the last month, the number of systems containing Commodities markets hasn't increased much (was about 6100 I think). This means we have slowed our data gathering. Just a reminder that the list MB gave us was around 18000 Systems containing markets - we've been to about a third. That means there would likely be approximately 20,000 stations that have markets that we haven't been trading at!! So don't forget to allocate at least some of your trading time to gathering new prices in systems for which we don't have existing data...
Some stats:
Of the 18032 Stations in the database, 13960 are market='Y', 3914 are market='?', 11859 actually have prices recorded.
4963 are ls_from_star = 0 (unknown distance), 12750 are < 1000Ls, 5282 are >= 1000Ls.
4706 are unknown pad size, 5936 are L pad, 7390 are M pad.
Only 2 stations are L pad but market N.
Of the 11857 stations with prices recorded, 4576 are L pad, 3706 are M pad, 3577 are ? pad.
