In-Development TradeDangerous: power-user trade optimizer

Additionally, no such place as Daruwutja/Acropolis - not sure where that comes from, though this must be a separate issue.

On reflection, I had literally only just today run -O clean, so either TD or EDDBlink had a brainfart on import or it's in the EDDB data - which is odd as I can't find reference to this station on either EDDB or EDSM.
 
On reflection, I had literally only just today run -O clean, so either TD or EDDBlink had a brainfart on import or it's in the EDDB data - which is odd as I can't find reference to this station on either EDDB or EDSM.
Odd. I'll look into it.
 
Last edited:
On reflection, I had literally only just today run -O clean, so either TD or EDDBlink had a brainfart on import or it's in the EDDB data - which is odd as I can't find reference to this station on either EDDB or EDSM.

It's definitely coming from EDDB:
systems_populated.jsonl:
{"id":4058,"edsm_id":6507,"name":"Daruwutja",...
station.jsonl:
{"id":69795,"name":"Acropolis","system_id":4058,...
listings.csv:
4799188,69795,2,9504,2,11,11,0,0,1529460526

This is obviously some kind of bug on EDDB's end because if you look in EDDB for station 69795, you get Acropolis, but it says it's in Nauni: https://eddb.io/station/69795

And Nauni is id 14217.
 
Also the bizarrely distant (but real) station it wanted to send me to. I took a snapshot of the data directory if you need it.

On that, I might be giving too much boost to close stations. I had a similar case last night where one of the hops was to a station 52.4Kls out, and hop right after was to a station 10ls out.
 
On that, I might be giving too much boost to close stations. I had a similar case last night where one of the hops was to a station 52.4Kls out, and hop right after was to a station 10ls out.

Okay, I can see how that would work. I wonder how far away TD thinks Daruwutja/Acropolis is.
 
eyeonus - Today at 2:42 PM
Hey guys, we here in the TD-revival camp have found an error in the nightly dumps from EDDB:
systems_populated.jsonl:
{"id":4058,"edsm_id":6507,"name":"Daruwutja",...
station.jsonl:
{"id":69795,"name":"Acropolis","system_id":4058,...
This is obviously some kind of bug on EDDB's end because if you look in EDDB for station 69795, you get Acropolis, but it says it's in Nauni: https://eddb.io/station/69795

Cometborne - Today at 2:46 PM
Acropolis is a mega ship, might have jumped from Daruwutja to Nauni with yesterday's maint
So it looks like there are one or more "stations" that can move between systems. That's annoying.
 
Last edited:
eyeonus - Today at 2:42 PM
Hey guys, we here in the TD-revival camp have found an error in the nightly dumps from EDDB:
systems_populated.jsonl:
{"id":4058,"edsm_id":6507,"name":"Daruwutja",...
station.jsonl:
{"id":69795,"name":"Acropolis","system_id":4058,...
This is obviously some kind of bug on EDDB's end because if you look in EDDB for station 69795, you get Acropolis, but it says it's in Nauni: https://eddb.io/station/69795

Cometborne - Today at 2:46 PM
Acropolis is a mega ship, might have jumped from Daruwutja to Nauni with yesterday's maint

Fair enough - I'ma go there and see.

So it looks like there are one or more "stations" that can move between systems. That's annoying.

And not just for us. There has been that odd one Orbis (Jaque's something) which has been moving for ages, but keeping up with a fleet of mobiles will add a new dimension to keeping up with the pricing for sure.
 
Last edited:
Fair enough - I'ma go there and see.

And not just for us. There has been that odd one Orbis (Jaque's something) which has been moving for ages, but keeping up with a fleet of mobiles will add a new dimension to keeping up with the pricing for sure.

Yeah, I can't do it. Any station that moves to a new system will fail to get updates until the nightly EDDB dump fixes it. EDDB doesn't get its ID numbers from EDDN, EDDN doesn't have any. TD uses the id numbers to store the listings.

Except for literally keeping a list of every mobile station with its EDDB id number and system id number, and putting in a special case in the message processor that updates the Station table when the damned thing moves, I can't think of anything that would make it possible to keep up with this kind of thing. And oh my NO, that's way too much effort, in part because of all the coding, but mostly because I don't even know if there's a way to get a list of all the mobile stations- and even if there is, I'm willing to bet it can't be done automatically.

IFF we could guarantee uniqueness in the name, we could just find the ID from the station name and update the system id if it changes, but the whole reason we're finding the id by SYSTEM/station is because we can't guarantee station name uniqueness.
 
Last edited:
Right, well I am now her in sunny Daruwatja and there's no sign of the Acropolis in the system map....

...next stop Nauni and see if I can find her there.

Edit: Oh wait, I misread it... jumped to Nauni *from* Daruwutja. Not vice versa.

Long story short, yes - verified she is at Nauni now. Oh... and 182.71ls from star.
 
Last edited:
Crap. That means I need to move the code that creates the SYSTEM/station = ID to inside the update checker, or it won't even be fixed then without a restart to the listener.
 
Yeah, I can't do it. Any station that moves to a new system will fail to get updates until the nightly EDDB dump fixes it. EDDB doesn't get its ID numbers from EDDN, EDDN doesn't have any. TD uses the id numbers to store the listings.

Except for literally keeping a list of every mobile station with its EDDB id number and system id number, and putting in a special case in the message processor that updates the Station table when the damned thing moves, I can't think of anything that would make it possible to keep up with this kind of thing. And oh my NO, that's way too much effort, in part because of all the coding, but mostly because I don't even know if there's a way to get a list of all the mobile stations- and even if there is, I'm willing to bet it can't be done automatically.

IFF we could guarantee uniqueness in the name, we could just find the ID from the station name and update the system id if it changes, but the whole reason we're finding the id by SYSTEM/station is because we can't guarantee station name uniqueness.

No, I agree with all of that. As there is no "station type" field, we'd have to create a hard coded list. If we had such a list of affected stations by ID rather than name, could we keep a data file (movingstations.csv or something) which listed them and their respective system ids and do a sanity check to make sure they still match when we download and process station.jsonl? If not then update the database and write back a new copy of movingstations.csv (or whatever) with latest information. No idea how difficult that is. Handwaving as usual.

In any event, it's a minority of stations, it doesn't happen often and actually, it may not be our problem. We are pulling a data feed and then processing the data. The place it needs fixing it the data source itself, ie eddb. If we make sure to run -O clean periodically (and today I might have caught it at just the worst moment) then the "bad" data will vanish when the database is rebuilt.

Edit: Heh! I think I just managed to restate your exact method, but in different words.

Edit again: Maybe worth reaching out to EDDB (and maybe others) to see how they plan to deal with it.
 
Last edited:
No you didn't catch it at the worst moment. The next dump should have the new system, but until that next dump happens, EDDB's stations.jsonl still says it's in Daruwhatsit.

EDIT: I think I've got the code changed to reload the dicts on an update worked out correctly, so that the moving stations will get updated in the dicts the listener uses to figure out what the station's id number is. Testing it now, will push once I'm reasonably sure I didn't mess anything up.
 
Last edited:
No you didn't catch it at the worst moment. The next dump should have the new system, but until that next dump happens, EDDB's stations.jsonl still says it's in Daruwhatsit.

That's my point though. If I had run that query yesterday, or had run clean tomorrow, it likely wouldn't even have cropped up.
 
Not sure how helpful this is, but stations.jsonl does indeed have a station type field.

So Acropolis, ID 69795 is listed as "Megaship" - which should at least help in tracking the ones we need to care about.
 
Not sure how helpful this is, but stations.jsonl does indeed have a station type field.

So Acropolis, ID 69795 is listed as "Megaship" - which should at least help in tracking the ones we need to care about.

Actually, yes, that should help. All we need in that case is a list of all the types of stations that are mobile, which I'm willing to bet consists of only Mega Ships and maybe one or two other types.

EDIT: Yeah, I'm pretty sure it's just the Megaships:
"type_id":1,"type":"Civilian Outpost"
"type_id":2,"type":"Commercial Outpost"
"type_id":3,"type":"Coriolis Starport"
"type_id":4,"type":"Industrial Outpost"
"type_id":5,"type":"Military Outpost"
"type_id":6,"type":"Mining Outpost"
"type_id":7,"type":"Ocellus Starport"
"type_id":8,"type":"Orbis Starport"
"type_id":9,"type":"Scientific Outpost"
"type_id":11,"type":"Unknown Outpost"
"type_id":12,"type":"Unknown Starport"
"type_id":13,"type":"Planetary Outpost"
"type_id":14,"type":"Planetary Port"
"type_id":15,"type":"Unknown Planetary"
"type_id":16,"type":"Planetary Settlement"
"type_id":17,"type":"Planetary Engineer Base"
"type_id":19,"type":"Megaship"
"type_id":20,"type":"Asteroid Base"
 
Last edited:
Actually, yes, that should help. All we need in that case is a list of all the types of stations that are mobile, which I'm willing to bet consists of only Mega Ships and maybe one or two other types.

Other than that one odd orbis station (which was the test for moving stations and is now a special case with lore/backstory) I believe there are any other station types which move. At least at present.
 
Back
Top Bottom