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

docs: Outline rules and caveats about data Augmentations

Browse Source 
* Many will need a location cross-check.
* Call out this need in the fssbodysignals README.
This commit is contained in:
Athanasius 2022-05-29 14:17:30 +01:00
parent 370cef676f
commit d10b081be4
No known key found for this signature in database
GPG Key ID: AE3E527847057C7D
2 changed files with 48 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/Developers.md
View File

@ -301,6 +301,48 @@ Horizons-only features disabled.
active, but in the non-Odyssey game client case you only get the Horizons
boolean.
#### Other data Augmentations
Some schemas mandate that extra data be added, beyond what is in the source
data, to aid Listeners.
This is usually related to specifying which system an event took place in, and
usually means ensuring there is the full set of:
1. `StarSystem` - the name of the system.
2. `SystemAddress` - the game's unique numerical identifier for the system.
3. `StarPos` - The system's co-ordinates.
Whilst it can be argued that any Listener should see preceding event(s) that
give any missing information where at least the system name or `SystemAddress`
is already in the event data, this might not always be true. So Senders MUST
add this data where required. It helps to fill out basic system information
(name, SystemAddress and co-ordinates).
However, there is a known game bug that can result in it stopping writing to
the game journal, and some observed behaviour implies that it might then later
resume writing to that file, but with events missing. This means any Sender
that blindly assumes it knows the current system/location and uses that for
these Augmentations might send erroneous data.
1. **Senders MUST cross-check available event data with prior 'location'
event(s) to be sure the correct extra data is being added.**
2. **Listeners SHOULD realise that any data added as an Augmentation might be
in error.**
For Senders, if the source data only has `SystemAddress` then you MUST check
that it matches that from the prior `Location`, `FSDJump` or `CarrierJump`
event before adding `StarSystem` and `StarPos` data to a message. Drop the
message entirely if it does not match. Apply similar logic if it is only
the system's name that is already present in data. Do not blindly add
`SystemAddress` or `StarPos`. Likewise, do not blindly add `StarPos` if the
other data is already in the source, without cross-checking the system name
and `SystemAddress`.
Listeners might be able to apply their own cross-check on received messages,
and use any mismatch with respect to what they already know to make a decision
whether to trust the augmented data. Flagging it for manual review is probably
wise.
### Server responses
There are three possible sources of HTTP responses when sending an upload
to EDDN.

6
schemas/fssbodysignals-README.md
View File

@ -28,10 +28,16 @@ in the Developers' documentation.
You MUST add a `StarSystem` string containing the name of the system from the
last `FSDJump`, `CarrierJump`, or `Location` event.
**You MUST apply a location cross-check, as per
[Other data augmentations](../docs/Developers.md#other-data-augmentations).**
#### StarPos
You MUST add a `StarPos` array containing the system co-ordinates from the
last `FSDJump`, `CarrierJump`, or `Location` event.
**You MUST apply a location cross-check, as per
[Other data augmentations](../docs/Developers.md#other-data-augmentations).**
#### Remove _Localised key/values
All keys whose name ends with `_Localised`, i.e. the `Type_Localised`
key/values in Signals.