I can confirm that if I put a copy of TradeDangerous.sql into $TD_DATA then it does try to create the database.
(I say try, but as it turns out, Centos 7 still has an outdated version of SQLite and so it barfs, but that's my problem, not yours)
Release Trade Dangerous (Est. 2015) Power user's highly configurable trade optimizer
- Thread starter Tromador
- Start date
I can confirm that if I put a copy of TradeDangerous.sql into $TD_DATA then it does try to create the database.
(I say try, but as it turns out, Centos 7 still has an outdated version of SQLite and so it barfs, but that's my problem, not yours)
Okay, changed a thing, built a thing, installed a thing, tested the installed thing, published the thing, installed the published thing, and tested the installed published thing, and the problem is solved, to the limits of my ability to make sure it all works. Apologies. v10.0.3
Last edited:
FYI - pip reports this as 10.1.0
Roger. CentOS is usually a good choice, direct copy from upstream Redhat, all the goodies, will run 'commercial' products who release for RH etc etc (like the Backup Exec agent), but is just backward in a couple of ways. I had hoped going to CentOS 7 would fix it, but they are still using outdated versions of some stuff, so I'm essentially repeating the procedure I had on the current server to build a Python3.7/Sqlite3.27.1 environment from scratch. And it's 0218 and I just fixed another problem which was stopping Python from building right and so I'll finish up tomorrow.
(Slightly fed up with CentOS at this point, but it's what the guys at my old workplace are willing to support and it's a free and gratis virtual host, so I guess I won't complain too loudly)
Hey gazelle, the edapi plugin can't get authentication for some reason. Any ideas?
Removing the authentication on Frontier and running it again prompted Frontier to authorize it the next time I ran it and it works again, so it has something to do with trying to authenticate after the token has expired.
Removing the authentication on Frontier and running it again prompted Frontier to authorize it the next time I ran it and it works again, so it has something to do with trying to authenticate after the token has expired.
Last edited:
So, on start up TDH2 will look to see if a manual path to TD has been set and if not it will use "pip show tradedangerous" to see if TD is installed via pip. If not it asks if the user wishes to install TD and does so if they select "Yes". If they select "No" then they are presented with the current locate trade.py dialog.
If TD has already been installed via pip then the results of the "pip show" command are parsed for the installed version and the list of available versions downloaded from the pypi server. The most recent version is determined and if the installed version does not match the most recent version the user is asked if they wish to upgrade. If they select 'Yes' then pip is used to upgrade TD and if they select 'No' then nothing is done.
It seems to work but it's late and I'm tired so I'll sleep on it and look at it another day and see if I can break it. The intention of this and the other mods I have recently made are to enable a virtually silent install. If you have python and ED in the default locations, then TDH2 will not ask you to locate them which was always a bit of a pain.
Once I'm happy with the changes I'll ask for a few testers to hammer it before releasing it into the wild.
Happy days!
Nice going, but you might want to check if TD is pip-installed before seeing if there's a manual path, for those people that upgrade from a manual install to a pip install version of TD, as well as checking that the manual path actually does point to an install of TD if you're not doing that already, in case those same upgraders deleted the old manual install TDH is pointing to.
Last edited:
You did the right thing. Frontier changed something and you have to deauthorize the application before trying again. EDMC had the same problem.
TDH2 currently checks to see if trade.py exists and can be opened if there is a manual path set, but that is all that it does. If the rest of the TD system is not present then TDH2 will fail to run any of the commands.
I'm in two minds about your suggestion as I deliberately did not did this so that if TD is manually installed, the user is not constantly asked if they want to pip install it. The check would be carried out every time TDH2 is started and personally I'd find it very irritating to be kept on asking if I wanted to pip install when I had set a manual path and did not want it pip installed.
I don't think that there is a win-win path for this so I'm of a mind to get the user to delete the manual path in the ini file to upgrade to pip installed. That way the manual install version will continue to work without the user having to do anything at all. If an upgrade to pip installed is required by the user then I'll include instructions in the Wiki for this based on your post above. The main thing would be moving the data folder under the TDH2 install folder and removing one line in the ini file and that should do the trick.
I'll test that scenario as well.
I just said to check if it's pip-installed before checking manual. I didn't say offer to install before checking for manual:
Code:
Check if TD is pip-installed.
If yes:
- check if TD is latest version
- If no:
-- offer to upgrade
-- If yes:
--- upgrade TD
- goto done.
If no:
- Check for manual path:
-- If yes:
--- test run (ex.: 'trade.py --help')
--- test run success:
---- goto done
(If we got here, that means TD isn't installed at all.)
Offer pip install:
- If yes:
-- pip install TD
- If no:
-- ask for location of trade.py
label done
Last edited:
I didn't say that you did. What I did say was that offering the install repeatedly was one of the reasons I did it the way I described, as I am offering the pip install, instead of the way you posited.
Right now I'm favouring not moving forward with the manual install version at all and setting up TDH2 for pip install TD only, but I'm still thinking about that.
Not entirely, it depends on how much you want to maintain backward compatibility. I'm not a great believer in that, generally speaking, since it tends to clutter up an application with effectively redundant code and usually only required by a small number of people. How many people want to manually check for TD updates, manually download them and unpack them over their existing installation? I certainly don't and I don't suppose many of the few TDH2 users do either.
So, you are correct, it is my program and manual TD install for TDH2 is going away now that TD can be installed and updated using pip. I see no valid reason to maintain both methods. TDH3 will be available real soon now.
Nice one Mark. Thanks for your work on TDH and I'm looking forward to TDH3!
I didn't even know TDH3 was a thing. What's the difference between 2 and 3?
Also, I had an idea: have you considered using the Registry to figure out where ED is installed?
For instance, I have ED installed via Steam, so I have this entry in my registry:
I imagine that everyone that purchased ED through Steam has that same key, only with the InstallLocation pointing to wherever ED is on their computer.
I have no idea what the registry would look like for someone that got ED some other way, but I don't imagine it would be hard to find out.
Also, I had an idea: have you considered using the Registry to figure out where ED is installed?
For instance, I have ED installed via Steam, so I have this entry in my registry:
Code:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Steam App 359320]
"DisplayIcon"="G:\\Steam\\steam\\games\\a9a0ab456790afb831c7246e1be5aa69642a19c8.ico"
"DisplayName"="Elite Dangerous"
"HelpLink"="http://support.steampowered.com/"
"InstallLocation"="G:\\Steam\\steamapps\\common\\Elite Dangerous"
"Publisher"="Frontier Developments"
"UninstallString"="\"G:\\Steam\\steam.exe\" steam://uninstall/359320"
"URLInfoAbout"="http://www.elitedangerous.com/"
"NoRepair"=dword:00000001
"NoModify"=dword:00000001I imagine that everyone that purchased ED through Steam has that same key, only with the InstallLocation pointing to wherever ED is on their computer.
I have no idea what the registry would look like for someone that got ED some other way, but I don't imagine it would be hard to find out.
TDH3 will be the release that only deals with TD installed via pip. Those people that don't want TD pip installed can remain on the latest 2 version but going forward it's pip.
By the way, I have to congratulate you and kmpm for a great piece of work, so easy to use, check and update, it was a really excellent move. So thanks.
I hadn't thought about querying the registry for the Elite install location as it isn't really where the logs are stored which is what TDH needs to access. For TDH3 I have used the official locations as published by FDev and if that fails to find the logs it will revert to the user location method.
Likewise for the python location. Here the environment PATH variable is parsed for python entries and if none found then the user is asked to locate the python exe file. Hopefully for the majority of cases this means that installing TDH will be a much easier process than before.
Last edited: