third-party-mirrors/EDDN
1
0
Fork 0
mirror of https://github.com/EDCD/EDDN.git synced 2025-06-15 14:52:06 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

schemas: codexentry: README: Also be specific for receivers

Browse Source 
They should expect to have to cope with any of the three scenarios,
being free to just drop the data if they only get `BodyName`.
This commit is contained in:
Athanasius 2021-10-13 14:21:03 +00:00
parent c59a9191b3
commit bc1618063c
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
schemas/codexentry-README.md
View File

@ -100,8 +100,19 @@ you MUST NOT include them.
## Receivers ## Receivers
As per ['BodyID and BodyName'](#bodyid-and-bodyname) above be aware that As per ['BodyID and BodyName'](#bodyid-and-bodyname) above be aware that
you are not guaranteed to reveice these values for any given event. Some you are not guaranteed to receive these values for any given event. Some
codex entries will be in space and thus they aren't even relevant. In codex entries will be in space, and thus they aren't even relevant. In
other cases it may not have been possible to properly determine both of them. other cases it may not have been possible to properly determine both of them.
So you might receive any of:
1. Neither `BodyName` nor `BodyID` present in the message, not even the
key names. This SHOULD indicate a codex entry object which is not on a
body surface.
2. `BodyName` key present with a value, but no `BodyID` key. This SHOULD
indicate a codex entry object which is on a body surface, but probably
where there is a close-orbiting binary companion which has confused things.
3. Both `BodyName` and `BodyID` keys present, with values. This SHOULD
indicate a codex entry object which is on a body surface.
Adjust your local processing accordingly. Adjust your local processing accordingly.