This looks like an FC but --FC N

[Tromador]

Unload at Chona/KBZ-5TX (1ls, Flc:N, Ody:N) => Gain 140,395,520cr (516,160cr/ton) => 620,750,190cr

Apparently offering a prince's ransom for tritium, so if it's true, I'll make a small fortune, but something looks off here. I'll know if it's an FC soon enough, but I'm 99% sure that's an FC designation.

[Tromador]

It's Victory Class Carrier "Voice of the Whirlwind". Whilst we're at it, doesn't TD know FCs have large pads? Mind you as it's not sure it's an FC at all...

C:\Program Files\Python312\Scripts\trade: ERROR: --to station Chona/KBZ-5TX does not meet pad-size requirement.
You specified: L, Current data for station: ? (Unk)
You can use "trade.py station" to correct this.

Of course this could be CAPI misbehaving and not for the first time today.

[Tromador]

Visiting is has corrected the (I knew it would be) total lies about the price he's buying tritium, but well - tritium is cheap. Maybe it's fixed the DB too.

[eyeonus]

Looks like TD didn't know a lot about this one:

station_id,name,system_id,ls_from_star,blackmarket,max_pad_size,market,shipyard,modified,outfitting,rearm,refuel,repair,planetary,type_id
3707246080,'KBZ-5TX',9468389303745,1,'?','?','Y','?','2024-04-23 00:36:19','?','?','?','?','?',0

Neither the listener nor spansh are set up to update station info.

The listener will need to be updated to listen to EDDN messages of the Journal schema and grab the info from any "Docked" messages in order to handle updating station info. This is planned but not happening "soon".

Spansh already has most of what it needs already, just need to make it check timestamps from the source vs the DB and update DB if source is newer.

[eyeonus]

The simplest solution is to do a blind replace, which has the benefit of also fixing the Rescue Ship name issue.

I'm testing how that affects the import, in terms of speed, etc.

[eyeonus]

fixed by https://github.com/eyeonus/Trade-Dangerous/commit/fa63e94a106088d28292a79829131cf938be34bc

[ultimatespirit]

Would it be possible to add a --min-ls parameter for minimum lightseconds away from the star or a --no-incomplete-data parameter or something like that. It seems these erroneous fleet-carriers-that-are-not-marked-as-such have in common a very sparse mostly default values set of data, including a default of 1ls from the star (something I believe even FCs jumped to a star can't have?) and very little info otherwise. Alternatively a clamp parameter according to galactic average for price, allowing you to say "remove any commodity that is being sold at x% over the galactic average" to ignore these sort of erroneous "way too good to likely be true" points that lead to pathological route finding cases. At least when you don't care for fleet carriers it's very unlikely a commodity price will ever go more than around 5x its average price to my knowledge.

Sure in the long run sanitising the data / updating it should remove these points, but until then they'll represent pathological cases in routing with --FC N set due to how out of whack the route optimiser will get if it can form a graph reaching one of these false points. So if we could specify a minimum lightseconds away for example that should prune out some of (if not all) these erroneous points, since no planet or station could possibly be at 1ls.

[eyeonus]

The mostly blank stations are added by the listener, because the commodities EDDN schema doesn't include any station information other than the market id. Currently, those stations get fixed after a subsequent Spansh update, because that data does contain the information, and listening to "docked" messages which also contain that info is in the works for the listener, but in the meantime I think just excluding any station with a type_id of 0 (== Unknown) whenever --FC n might be a good enough workaround, yeah?

[ultimatespirit]

Yea, excluding type_id == 0 sounds even better

[eyeonus]

Stations of unknown type now considered Fleet Carriers as of v11.1.3

Also, Oliver did some improvements to the build process, so we shouldn't be getting new versions quite as often.