* 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.
* Removed scripts/run-from-source.sh as it's now redundant.
* Added `--background` optional argument, only for when using
`--from-source` to start-eddn-service. The script will leave the
service in the foreground, no output redirection, without it.
It tells you the PID of the process when it's backgrounded, as well as
placing it in the appropriate .pid file.
* <hr> between sections
* Document the ports that *must* be open to the internet.
* Apache will require the proxy_http module.
* Move the github clone earlier in instructions, as part of ensuring
paths exist when they should.
* Note about needing to do hostname and port substitutions in monitor
files if not using the standard values.
* Link to other sections where appropriate.
Athanasius
Athanasius