All schemas: New `gameversion` *header* field

[Athanasius]

NB: Keep discussion of any changes to horizons and odyssey flags semantics/requirements over in #196

As 4.0 Horizons client is launching soon we need to be sure Listeners can distinguish what game client and game mode a message has come from.

Rather than rely on some tweaks to the horizons and odyssey flag requirements (which have always been optional), let's just add an, initially optional (to give Senders time to update), gameversion header key:value to the header of all messages.

As per #196 the one place this might be problematic is in CAPI-sourced, non-Journal, messages, i.e. commodity, shipyard, outfitting. But those might be in less need of the disambiguation anyway.

[bgol]

Maybe use a Pseudo-Version like CAPI if it is the source of the message.

[Athanasius]

Maybe use a Pseudo-Version like CAPI if it is the source of the message.

This idea definitely has merit. I can't see that ever clashing with a Journal->LoadGame->gameversion value.

It does feel slightly like inching towards "we should just add that data-source header Ath occasionally moots" though.

[Athanasius]

There are events written to a journal before LoadGame shows up

Horizons has all of these events between FileHeader and first LoadGame: Commander, Materials, Rank, Progress, Reputation.

Odyssey: Commander, Materials, Rank, Reputation, EngineerProgress, SquadronStartup

So nothing game-breaking for the purposes of EDDN.

[robbyxp1]

Okay, why are we not setting gameversion to the FileHeader value. That comes first, should be the same as LoadGame, and copes with any events that might occur before LoadGame in the future.

[Athanasius]

Okay, why are we not setting gameversion to the FileHeader value. That comes first, should be the same as LoadGame, and copes with any events that might occur before LoadGame in the future.

If we mandate that then it doesn't work for any Sender using CAPI /journal, as that doesn't have it. There's at least: Journal Limpet and EDSM Console. If we were to make any decision that doesn't work for those then I'd like to hear from EDDN Listeners first about the possible impact.

I'd rather just say "from LoadGame" and we'll react if that's ever too late for EDDN messages, than have an exception.

[Athanasius]

I'll review all my journals to be extra sure there are no instances of differences between FileHeader->gameversion and LoadGame->gameversion, but on reflection I see no reason why we can't:

1. Mandate that, where available, the gameversion from FileHeader can be used by default.
2. Where it is not available, use gameversion from LoadGame.
3. If in the future any EDDN-relevant events occur before LoadGame then those messages should be held until after it, in the case of LoadGame being the source of gameversion.

[klightspeed]

3. If in the future any EDDN-relevant events occur before LoadGame then those messages should be held until after it, in the case of LoadGame being the source of gameversion.

I would think that any program that wants to link journal entries to commanders would already do something like this - e.g. in the journal entry stream, EDDiscovery queues up events until it sees a LoadGame

[Athanasius]

And Horizons Journals, still, don't have gameversion in LoadGame.

That means we can't make this new field mandatory until that changes. We can absolutely still add it ASAP as optional, with documentation saying that anyone using direct Journal files MUST add it.

{ "timestamp":"2022-09-14T15:16:36Z", "event":"Fileheader", "part":1, "language":"English\\UK", "Odyssey":false, "gameversion":"3.8.0.407", "build":"r285813/r0 " }
...
{ "timestamp":"2022-09-14T15:16:59Z", "event":"LoadGame", "FID":"F32434", "Commander":"Athanasius", "Horizons":true, "Ship":"Python", "ShipID":6, "ShipName":"Dobbin", "ShipIdent":"CH-WHS", "FuelLevel":32.000000, "FuelCapacity":32.000000, "GameMode":"Solo", "Credits":499928296, "Loan":0 }

[Athanasius]

The adjusted schemas, having been tested on beta with and without the new fields, are now up on the live service.