I wonder what happened to type_id 10
In-Development TradeDangerous: power-user trade optimizer
- Thread starter kfsone
- Start date
I wonder what happened to type_id 10
Cool. I just need the name of that one station then.
No idea, but probably the same thing that happened to type_id 18.
EDIT: Hmm... Looks like I'll need to modify the Station table to include the station type.
Last edited:
Ok - With the raft of recent changes, I've rebuilt the server from scratch with the latest TD, the listener you just pushed and a clean dataset. Seems to be running right.
"id":42041,"name":"Jaques Station","system_id":633211
Presently in Colonia, having started in Alshain, with its first (test) move being during beta.
I believe it moves very infrequently. It's been in Colonia for ages.
So, the commodities schema doesn't include the ls from star, so that won't get updated until the next EDDB dump without a rewrite to the listener to include journals messages and special processing for those. I don't really want to do that just to update the ls when it'll happen on its own with the dump....
I think just getting the right system should be enough, yeah?
I think just getting the right system should be enough, yeah?
Yeah, definitely. We don't want to be overly picky just for 21 special cases.
Okay, both EDDBlink plugin and eye-TD have been updated to include the type_id of the station so the listener can use that to track the mobile stations.
You won't need to do a clean run if you upgrade, BTW, as it will add the column to the existing database if it's not there already.
Working on the listener part now.
EDIT: In case you already updated, I found a small bug- some of the entries in the jsonl don't have a value for type_id, so there;s an update that deals with that case.
You won't need to do a clean run if you upgrade, BTW, as it will add the column to the existing database if it's not there already.
Working on the listener part now.
EDIT: In case you already updated, I found a small bug- some of the entries in the jsonl don't have a value for type_id, so there;s an update that deals with that case.
Last edited:
Someone go dock at one of the megaships so I can get an update.
Your ship lost it's engines?
I am in Ceos, want to bet on who is closest?
Okay, someone docked at Jaques Station in Colonia, so I was able to verify everything I need to:
The dict is being built correctly, with mobile stations being assigned as "MEGASHIP/STATION_NAME" instead of "SYSTEM_NAME/STATION_NAME" so that processing is easier for them.
The message processor successfully finds the "MEGASHIP/" stations.
Normal stations that stay frakkin' put are unaffected by this change.
I've got some debug text to remove and then there'll be a push.
If you haven't updated the plugin and decide to update the listener, you'll need to do so before running the listener. You don't need to run the plugin, the listener will do it, you just have to make sure it's been updated.
You don't need to clean the DB, but it is recommended because if you don't, the stations in the DB won't be updated with the type_id until the next EDDB update occurs. This won't cause any issues, but updates to mobile stations that have moved to a new system won't occur until that happens, because the plugin handles updating the stations' type_ids, and it won't do that until it has new data to toss in, so you'll still see "ERROR: Not found in Stations: " messages until the EDDB update.
The dict is being built correctly, with mobile stations being assigned as "MEGASHIP/STATION_NAME" instead of "SYSTEM_NAME/STATION_NAME" so that processing is easier for them.
The message processor successfully finds the "MEGASHIP/" stations.
Normal stations that stay frakkin' put are unaffected by this change.
I've got some debug text to remove and then there'll be a push.
If you haven't updated the plugin and decide to update the listener, you'll need to do so before running the listener. You don't need to run the plugin, the listener will do it, you just have to make sure it's been updated.
You don't need to clean the DB, but it is recommended because if you don't, the stations in the DB won't be updated with the type_id until the next EDDB update occurs. This won't cause any issues, but updates to mobile stations that have moved to a new system won't occur until that happens, because the plugin handles updating the stations' type_ids, and it won't do that until it has new data to toss in, so you'll still see "ERROR: Not found in Stations: " messages until the EDDB update.
Last edited:
Thanks Tromador!
You are welcome, I am glad to have provided an entertaining diversion.
Don't forget though - working on a tool for a game is often a fun and rewarding activity, but try to get some decent gameplay in to balance.
I will push to server after some sleep (if my insomnia ever quits - stupid illness, stupid meds).
Last edited:
The boost part of the penalty equation, yes.
But apparently the default penalty is not 0.05, but 0, as you can see in the code snippet above, which means unless an lspenalty is passed on the command line, ls distance isn't factored in at all. So, I reverted the boost and fixed the default setting. If it still turns out that high distance stations are showing up a lot, I'll revisit this.
I'm also pretty doubtful that a low distance hop would affect the likelihood of seeing a high distance hop, so if I do revisit it, I'll probably try sharpening the drop curve before I do any adjusting to the boost curve.
Last edited:
Yup. Sounds good - with the following correction.
It was I who stated the default setting of 0.5 (not 0.05) as per the documentation. Thus you need to either match the existing document, or if that is not a sensible setting with your new curve, then we need to update the doc.
Edit: Might not be a bad idea to give advice in the documentation as to some reasonable upper and lower limits for this setting.
It was I who stated the default setting of 0.5 (not 0.05) as per the documentation. Thus you need to either match the existing document, or if that is not a sensible setting with your new curve, then we need to update the doc.
Edit: Might not be a bad idea to give advice in the documentation as to some reasonable upper and lower limits for this setting.
Code:
--ls-penalty N.NN
--lsp N.NN
DEFAULT: 0.5
Reduces the score of routes by this percentage for every 1000ls
you have to travel to stations, which helps prioritize routes
with a shorter supercruise time.
e.g.
--ls-penalty 2.5
--lsp=0 (disables this feature)
Last edited:
Speaking of documentation, I am planning to really cut down on the length of that readme and migrate the information into the wiki. It's completely lost down the page under the source files and it doesn't make sense to me to effectively have two lots of documentation, often repeating the same information.