In-Development TradeDangerous: power-user trade optimizer

Coriolis/EDDB managed to disagree on the name of the Krait in their respective output which caused the plugin to barf if you run 'clean' (and I suspect if you run 'all') TD will barf.

I've pushed a fix for that....
I fixed Trom's Krait "fix" and also included a "pre-fix" for other possibilities. I don't know why different groups abbreviate "Mark" differently (, i.e "MK II", "Mk II", "MkII", etc.), but here in eye-TD we always abbreviate it "Mk." (, i.e. "Mk. II"), because that's the grammatically correct way to do it.

(Make sure to run an eddblink plugin update with the "shipvend" option after upgrading just to make sure everything's hunky-dory.)
 
Last edited:
Having come across annoyances with ancient versions of python & sqlite libraries even on the latest Redhat Linux, I wonder (as a stab in the dark) if you might be experiencing the same on MacOS (if that's what you are testing).

Example - checking SQLite version on my PC.
Code:
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.sqlite_version
'3.21.0'
Your minimum version for FK support is 3.6.19
I'm up to date with everything but I've narrowed it down to the shape of the SQL statement. If I use the old non-join syntax it seems to work as expected. Using the join syntax, however, gives the error. Both commands work if I use a SQLite Database Browser and execute the SQL therein. So, it's seems to be something to do with .Net. Really odd. But there's a workaround that doesn't show the error so I'm going to leave it at that for the moment.
 
I'm up to date with everything but I've narrowed it down to the shape of the SQL statement. If I use the old non-join syntax it seems to work as expected. Using the join syntax, however, gives the error. Both commands work if I use a SQLite Database Browser and execute the SQL therein. So, it's seems to be something to do with .Net. Really odd. But there's a workaround that doesn't show the error so I'm going to leave it at that for the moment.
Stupid Micro$oft messing everything up. I wonder if the same thing would happen in Mono? Anyway, glad to hear you're making progress.

In other news, I think Trom and I have decided to release TD, now that there's no open issues anymore. Yay fixings. I think someone asked if they could point the tool websites to eye-TD? I don't know how, so unless Trom does and wants to do it himself, I'm all for it.
 
I'm up to date with everything but I've narrowed it down to the shape of the SQL statement. If I use the old non-join syntax it seems to work as expected. Using the join syntax, however, gives the error. Both commands work if I use a SQLite Database Browser and execute the SQL therein. So, it's seems to be something to do with .Net. Really odd. But there's a workaround that doesn't show the error so I'm going to leave it at that for the moment.
Then the error most likely comes from your C# object and not the database. The "left join" is an outer join, so the "stn_name" of your select may be NULL. Check if your data object does allow DBNull values.
 
Then the error most likely comes from your C# object and not the database. The "left join" is an outer join, so the "stn_name" of your select may be NULL. Check if your data object does allow DBNull values.
That's not the issue. Use the DataTable object and call the Load method passing in the reader and the exception is thrown. Read from the reader one record at a time and add this to the DataTable using the LoadDataRow method and the exception is not thrown. Nothing else changes, not the SQL command not the reader not the data table, just the way in which the data table is populated.

Do the same thing with the old, non-join syntax and the Load method of the data table does not throw the exception.

It seems that .NET might be checking the schema constraints if the Load method is called and not otherwise and it is doing this whether or not the Foreign Key constraints are enabled or not.
 
Last edited:
Stupid Micro$oft messing everything up. I wonder if the same thing would happen in Mono? Anyway, glad to hear you're making progress.

In other news, I think Trom and I have decided to release TD, now that there's no open issues anymore. Yay fixings. I think someone asked if they could point the tool websites to eye-TD? I don't know how, so unless Trom does and wants to do it himself, I'm all for it.
Sometime Microsquish does things that seem like a good idea but turn out to be a whole heap of garbage. I don't know about Mono, I suppose it depends on how close Mono is emulating .NET.

Pointing the Tool websites to their new home is a good idea as far as I'm concerned, Ive set one up for TD Helper which didn't have one before but I need to update that as I release TDH2 to production at the last release since I've had no other issues arise.
 
Last edited:
Do the same thing with the old, non-join syntax.
The non-join syntax is still a join.
Code:
SELECT System.name, Station.name FROM System, Station WHERE System.system_id = Station.system_id;
-- is the same as
SELECT System.name, Station.name FROM System INNER JOIN Station ON System.system_id = Station.system_id;
 
The non-join syntax is still a join.
Code:
SELECT System.name, Station.name FROM System, Station WHERE System.system_id = Station.system_id;
-- is the same as
SELECT System.name, Station.name FROM System INNER JOIN Station ON System.system_id = Station.system_id;
Apparently not. At least not as far as the DataTable in .NET is concerned when loading from an SQLiteDataReader. If they were the same then either they would both throw the same exception or they both would not. The situation is that one form does throw an exception whereas the other form does not, therefore there is a functional difference between the two forms in this instance.

Technically, according to the SQL syntax, the two commands describe a join between tables and should provide identical results, in practice however, this .NET/DataTable/SQLiteDataReader combination appears to treat the two forms differently.
 
Mark, if you are about ready to release TDH2, then it might be nice to coordinate such that we perform a simultaneous release.
 
Mark, if you are about ready to release TDH2, then it might be nice to coordinate such that we perform a simultaneous release.
Cmdr eyeonus raised two issues that I need to squash. I also removed the 'beta' tag from TDH2 with the 2.0.4.0 release, meaning of course that issues would immediately arise!

I should have the two issues dealt with this afternoon.
 
Cmdr eyeonus raised two issues that I need to squash. I also removed the 'beta' tag from TDH2 with the 2.0.4.0 release, meaning of course that issues would immediately arise!

I should have the two issues dealt with this afternoon.
Speaking of which, I think at least some of these are due to those issues:

The only fields getting filled are the credits, insurance, and capacity;

I can't save a profile manually, I can't load a profile manually, I can't name a profile at all, I can't figure out where the profiles are being stored;

The profile loader isn't backwards-compatible with Wombat's TD (as in it doesn't recognize or load Wombat profiles), which seems odd to me, since I would assume that the new profiles are the same as the old profiles except with the common stuff
removed, so why not just load the not common stuff (although this could be due to the profiles no longer being stored in the main TDH folder like they used to be?);

I wish the interface wasn't so wide, and related to that, the groupings and locations of the various boxen seems random and chaotic, especially as compared to the old layout.
 
Last edited:
Speaking of which, I think at least some of these are due to those issues:

The only fields getting filled are the credits, insurance, and capacity;
For one of the exceptions, it was a question of what fields in the Cmdr profile were always present and those that were not. The Ship Name, for example, is not present if the commander has not named the ship whereas the internal ship ID is always present. Also only the currently selected ship is fully described in the profile. The commander's other ships, if any, only have a minimal description, so cargo capacity, for example, is only available for the currently selected ship.

The other exception was due to an empty string not being a valid decimal number in string format. Ensuring that this is "0" when found solves the issue.

I can't save a profile manually, I can't load a profile manually, I can't name a profile at all, I can't figure out where the profiles are being stored;
Save settings button. All settings are now save in one file TDH.ini and not in separate XML files.

The profile loader isn't backwards-compatible with Wombat's TD (as in it doesn't recognize or load Wombat profiles), which seems odd to me, since I would assume that the new profiles are the same as the old profiles except with the common stuff
removed, so why not just load the not common stuff (although this could be due to the profiles no longer being stored in the main TDH folder like they used to be?);
Correct, it is not backwards compatible and hence the TD2 designator. Of course, I could always call is something completely different.

I wish the interface wasn't so wide, and related to that, the groupings and locations of the various boxen seems random and chaotic, especially as compared to the old layout.
I have to disagree with you here, I laid out the controls in a less chaotic fashion that the original. We'll just have to disagree on that one.

I took a 'sort of working' version of TD Helper and modified it to suit my needs and prejudices. Maybe some people will find it useful, others will not. You can always use the latest version of the original TD Helper and run the Database updates from the command line, that still works fine.
 
I can't save a profile manually, I can't load a profile manually, I can't name a profile at all, I can't figure out where the profiles are being stored;
Save settings button. All settings are now save in one file TDH.ini and not in separate XML files.
I said profile, not settings. As in whatever is still stored on a per-ship basis. I only have the "default" profile, I can't save it, I can't rename it, I can't load a different one.

Again, probably due to the github issues, but here's a picture of what I'm talking about:
And yet:
From "tdh.ini":
Code:
[Default]
Capacity=1
LadenLY=1
Padsizes=?
UnladenLY=1

[Cobra MkIII (calamity jane)]
Capacity=36
LadenLY=1
Padsizes=?
UnladenLY=0

[Cobra MkIII eye-01 (calamity jane)]
Capacity=36
LadenLY=1
Padsizes=?
UnladenLY=0
Note that both the Cobra entries were made automatically by the "Cmdr Profile" button.

I have to disagree with you here, I laid out the controls in a less chaotic fashion that the original. We'll just have to disagree on that one.
Some examples of what strikes me as random:

"Avoid" and "Via" are on the completely opposite side of the UI to "Source" and "Destination", all four of which are used in route plotting.

"Prune Hops" is in the box with "Hops" and "Jumps", but "Prune Score" is in the box with "Loop Int".

"Age" is in the same box as "Credits".

The box containing the run-type dropdown is 5 lines high, but no run-type needs more than two lines.

"Loop Int" only matters when Loop is enabled, which can only happen when doing a "Run", but it's never grayed out and is on the other side of the UI from the Loop checkbox.

(Admittedly, some of those things are true in Wombat's TDH as well.)
 
I said profile, not settings. As in whatever is still stored on a per-ship basis. I only have the "default" profile, I can't save it, I can't rename it, I can't load a different one.

Again, probably due to the github issues, but here's a picture of what I'm talking about:
And yet:
From "tdh.ini":
Code:
[Default]
Capacity=1
LadenLY=1
Padsizes=?
UnladenLY=1

[Cobra MkIII (calamity jane)]
Capacity=36
LadenLY=1
Padsizes=?
UnladenLY=0

[Cobra MkIII eye-01 (calamity jane)]
Capacity=36
LadenLY=1
Padsizes=?
UnladenLY=0
Note that both the Cobra entries were made automatically by the "Cmdr Profile" button.



Some examples of what strikes me as random:

"Avoid" and "Via" are on the completely opposite side of the UI to "Source" and "Destination", all four of which are used in route plotting.

"Prune Hops" is in the box with "Hops" and "Jumps", but "Prune Score" is in the box with "Loop Int".

"Age" is in the same box as "Credits".

The box containing the run-type dropdown is 5 lines high, but no run-type needs more than two lines.

"Loop Int" only matters when Loop is enabled, which can only happen when doing a "Run", but it's never grayed out and is on the other side of the UI from the Loop checkbox.

(Admittedly, some of those things are true in Wombat's TDH as well.)
The default profile is only there until you update the commander's profile then it should be replaced by an entry for each of the commander's ships. If it is still there and the your ships are not showing, then that is bug I need to look into.

The settings include the ship and commander profiles.

The problem with 'Avoid' is that it is a multi-purpose field allowing not only the avoidance of systems but also of stations and commodities. As a result its location on the form really depends on its current purpose. I rarely use it for avoiding systems and station and mainly for avoiding commodities. Bear also in mind that 'Avoid' and 'Via' are pretty much in the same place as in the original version of TD.

The issue with Loop Int not being enabled or disabled in the correct place is another original TD thing.

Age and credit don't really belong anywhere so they were put in a convenient space.

I think moving 'Loop int' into the same panel as 'Loops' and have it enabled and disabled as with that checkbox is probably a good idea and 'Prune score' and 'Prune hops' perhaps belong in the same box as 'Max LS' and 'LS penalty'.

And the run box being as high as it is? Cos it fits in that space. Raggedy edges are irritating to me so I avoid them.

And so it goes on your thoughts versus my thoughts. I agree with some of them but the others are because I want them to be that way. I'll have anther look at re-aranging the layout but I'm not going to undertake a redesign. Someone else can take a stab at that.

Both Cobra entries is an interesting one, you must have just updated from the source today since I have only just added the call-sign to the section header to avoid the problem where a commander has more than one ship of the same type. That suggest to me that the removal of ships no longer found in the Commander's Profile is definitely not working and I'll take look at that.

[Edit] How's this:

 
Last edited:
Why not put "Age" in with the other limiting options, the prunes and max LS - Also move the Max LS and LS penalty to the top as they are more commonly used, perhaps with age above those.

If you wanted to then fill the Credits box to make it balanced along the rows with the ship stuff, you could maybe autofill the commander name in above credits, but that would be purely aesthetical.

Just possibly, I guess you could even put the "run" dropdown in the place of age (assuming you move age per my suggestion). Then you would have the query type just below the "RUN" button.

Speaking of the RUN button - that might possibly be confusing as "Run" is a query type. How about "Go" instead?

Another place for the query type dropdown might be on the same row with the buttons, rearranging so it's next to the run (or GO) button.

Why can't "Local" just be on the dropdown and has to have its own tickbox? That doesn't make sense as all other basic query types are on the dropdown.


Finally, I would suggest that IF IT WORKS then you could release it if you wanted, fiddling with the aesthetics/ergonomics is important, but I don't think it's that terrible so as to be worth stopping a release.


Also, from your readme on Github, whilst it is of course in good taste to mention Oliver, including a link to his TD repository may be confusing. Can I suggest that you edit the "What is this tool supposed to do?" to reflect the current state of play.
 
Last edited:
The default profile is only there until you update the commander's profile then it should be replaced by an entry for each of the commander's ships. If it is still there and the your ships are not showing, then that is bug I need to look into.
Then it is a bug you need to look into. The screenshot was taken after updating the profile, as you can see from the output.
 
TD is weird. It has a --planetary option, and a --no-planet option. Since '--no-planet' is the same thing as '--planetary N', why the redundancy Oliver? Why? :D
That was me. I first did the --no-planet option when I added the planetary column to the station. The --planetary came later and I just didn't remove the old one (backwards compatibility and what not), just made them mutually exclusive.
 
Theoretically we are on a feature freeze pending release, but how hard would it be to remove the --no-planet option, being as it is redundant?
 
Top Bottom