* The ordered-list advice is for `gameversion`, not `gamebuild`. So move
the latter mention below that list.
* Also mention `fcmaterials_capi` comes from `market` endpoint.
The emphasis here is on strongly encouraging Senders to get the actual, full
and correct, values to Listeners. But where they can't, be that due to
data source limitations (CAPI), or their code architecture (common EDDN
sending code that has no concept of the data source), they're allowed to
send a less than optimal value.
**BUT**, they still should start sending the fields as outlined.
* Actually define what we expect from the existing fields.
* Document what should go in the new `gameversion` and `gamebuild` fields.
* Update the generic example to include all of these "what version of the game,
or feature set, did this come from?" fields.
* Listeners really do need these, where defined in the schemas, so state
that they're mandatory.
* REALLY emphasise that where an `Odyssey` flag isn't in `LoadGame` Senders
MUST NOT send it with a `false` value.
Although pending addition of header->gameversion will aid Listeners,
currently this could give the misleading impression that a 3.8 Horizons
client is a 4.0 Horizons client.
This includes the new `4.0 Horizons` client, which changes the semantics
of what the `Odyssey` flag in the `Fileheader` means. It now indicates if
the client is a 4.0+ one, not if the player is utilising Odyssey DLC.
This causes issues, at the least, with compressed messages that 'look' like
they decompressed body is form-encoded. 18385 messages in the last month
rejected due to this.
No actually valid form-encoded messages in that time frame.
* Most of it is once more in schemas/README.
* But keeping the horizons/odyssey flags in docs/Developers.md, as that's
more about how you handle them in code.
Athanasius
Athanasius