From 329d59831fe4b00ff73979ce31b9d9502d8168b3 Mon Sep 17 00:00:00 2001 From: Athanasius Date: Tue, 14 Jun 2022 13:59:13 +0100 Subject: [PATCH 1/6] schemas/fsssignaldiscovered: Rework based on in-game findings 1. Unix, not DOS, line-endings. 2. `message`->`timestamp` instead of per signal. 3. `message`->`SystemAddress` instead of per signal. 4. `StarSystem` and `StarPos` augmentations now mandatory. --- schemas/fsssignaldiscovered-v1.0.json | 204 +++++++++++++------------- 1 file changed, 103 insertions(+), 101 deletions(-) diff --git a/schemas/fsssignaldiscovered-v1.0.json b/schemas/fsssignaldiscovered-v1.0.json index 8d23066..f649e2f 100644 --- a/schemas/fsssignaldiscovered-v1.0.json +++ b/schemas/fsssignaldiscovered-v1.0.json @@ -1,101 +1,103 @@ -{ - "$schema" : "http://json-schema.org/draft-04/schema#", - "id" : "https://eddn.edcd.io/schemas/fsssignaldiscovered/1#", - "description" : "EDDN schema for FSSSignalDiscovered Journal events. Full documentation at https://github.com/EDCD/EDDN/tree/master/schemas/fsssignaldiscovered-README.md", - "type" : "object", - "additionalProperties" : false, - "required": [ "$schemaRef", "header", "message" ], - "properties": { - "$schemaRef": { - "type" : "string" - }, - "header": { - "type" : "object", - "additionalProperties" : true, - "required" : [ "uploaderID", "softwareName", "softwareVersion" ], - "properties" : { - "uploaderID": { - "type" : "string" - }, - "softwareName": { - "type" : "string" - }, - "softwareVersion": { - "type" : "string" - }, - "gatewayTimestamp": { - "type" : "string", - "format" : "date-time", - "description" : "Timestamp upon receipt at the gateway. If present, this property will be overwritten by the gateway; submitters are not intended to populate this property." - } - } - }, - "message": { - "type" : "object", - "description" : "Contains all properties from the listed events in the client's journal minus Localised strings and the properties marked below as 'disallowed'", - "additionalProperties" : false, - "required" : [ "event", "signals"], - "properties" : { - "event": { - "enum" : [ "FSSSignalDiscovered" ] - }, - "horizons": { - "type" : "boolean", - "description" : "Whether the sending Cmdr has a Horizons pass." - }, - "odyssey": { - "type" : "boolean", - "description" : "Whether the sending Cmdr has an Odyssey expansion." - }, - "signals": { - "type": "array", - "description": "Array of FSSSignalDiscovered events", - "minItems": 1, - "items": { - "type": "object", - "required": ["SystemAddress", "timestamp", "SignalName"], - "description": "Single FSSSignalDiscovered event", - "properties": { - "SystemAddress": { "type": "integer" }, - "timestamp": { - "type" : "string", - "format" : "date-time" - }, - "SignalName": { "type": "string" }, - "IsStation": { "type": "boolean" }, - "USSType": { - "type": "string", - "not": { - "pattern": "^\\$USS_Type_MissionTarget;$" - } - }, - "TimeRemaining": {"$ref" : "#/definitions/disallowed"}, - "SpawningState": {"type": "string"}, - "SpawningFaction" : {"type": "string"}, - "ThreatLevel": {"type": "integer" }, - - "patternProperties": { - "_Localised$" : { "$ref" : "#/definitions/disallowed" } - } - } - } - }, - "systemName": { - "type" : "string", - "minLength" : 1, - "description": "Should be added by the sender" - }, - "StarPos": { - "type" : "array", - "items" : { "type": "number" }, - "minItems" : 3, - "maxItems" : 3, - "description" : "Should be added by the sender" - } - } - } - }, - "definitions": { - "disallowed" : { "not" : { "type": [ "array", "boolean", "integer", "number", "null", "object", "string" ] } } - } -} +{ + "$schema" : "http://json-schema.org/draft-04/schema#", + "id" : "https://eddn.edcd.io/schemas/fsssignaldiscovered/1#", + "description" : "EDDN schema for FSSSignalDiscovered Journal events. Full documentation at https://github.com/EDCD/EDDN/tree/master/schemas/fsssignaldiscovered-README.md", + "type" : "object", + "additionalProperties" : false, + "required": [ "$schemaRef", "header", "message" ], + "properties": { + "$schemaRef": { + "type" : "string" + }, + "header": { + "type" : "object", + "additionalProperties" : true, + "required" : [ "uploaderID", "softwareName", "softwareVersion" ], + "properties" : { + "uploaderID": { + "type" : "string" + }, + "softwareName": { + "type" : "string" + }, + "softwareVersion": { + "type" : "string" + }, + "gatewayTimestamp": { + "type" : "string", + "format" : "date-time", + "description" : "Timestamp upon receipt at the gateway. If present, this property will be overwritten by the gateway; submitters are not intended to populate this property." + } + } + }, + "message": { + "type" : "object", + "description" : "Contains all properties from the listed events in the client's journal minus Localised strings and the properties marked below as 'disallowed'", + "additionalProperties" : false, + "required" : [ "event", "timestamp", "SystemAddress", "StarSystem", "StarPos", "signals"], + "properties" : { + "event": { + "enum" : [ "FSSSignalDiscovered" ] + }, + "horizons": { + "type" : "boolean", + "description" : "Whether the sending Cmdr has a Horizons pass." + }, + "odyssey": { + "type" : "boolean", + "description" : "Whether the sending Cmdr has an Odyssey expansion." + }, + "timestamp": { + "type" : "string", + "format" : "date-time" + }, + "SystemAddress": { + "type": "integer" + }, + "signals": { + "type": "array", + "description": "Array of FSSSignalDiscovered events", + "minItems": 1, + "items": { + "type": "object", + "required": ["SignalName"], + "description": "Single FSSSignalDiscovered event", + "properties": { + "SignalName": { "type": "string" }, + "IsStation": { "type": "boolean" }, + "USSType": { + "type": "string", + "not": { + "pattern": "^\\$USS_Type_MissionTarget;$" + } + }, + "TimeRemaining": {"$ref" : "#/definitions/disallowed"}, + "SpawningState": {"type": "string"}, + "SpawningFaction" : {"type": "string"}, + "ThreatLevel": {"type": "integer" }, + + "patternProperties": { + "_Localised$" : { "$ref" : "#/definitions/disallowed" } + } + } + } + }, + "StarSystem": { + "type" : "string", + "minLength" : 1, + "description": "Should be added by the sender" + }, + "StarPos": { + "type" : "array", + "items" : { "type": "number" }, + "minItems" : 3, + "maxItems" : 3, + "description" : "Should be added by the sender" + } + } + } + }, + "definitions": { + "disallowed" : { "not" : { "type": [ "array", "boolean", "integer", "number", "null", "object", "string" ] } } + } +} From 86f56eaac2bc5e12574bb857c3300e13be4745e9 Mon Sep 17 00:00:00 2001 From: Athanasius Date: Tue, 14 Jun 2022 14:01:36 +0100 Subject: [PATCH 2/6] schemas/fsssignaldiscovered README: Reworked for changed schema * Purely event-based batching, no timer. * Outline Horizons/Odyssey differences. * Point out that USS are manually scanned, so different in time nature. * StarSystem renamed from systemName. * StarSystem and StarPos now mandatory. --- schemas/fsssignaldiscovered-README.md | 295 +++++++++++++++----------- 1 file changed, 173 insertions(+), 122 deletions(-) diff --git a/schemas/fsssignaldiscovered-README.md b/schemas/fsssignaldiscovered-README.md index f07d8ae..6665b22 100644 --- a/schemas/fsssignaldiscovered-README.md +++ b/schemas/fsssignaldiscovered-README.md @@ -1,122 +1,173 @@ -# EDDN FSSSignalDiscovered Schema - -## Introduction -Here we document how to take data from an ED `FSSSignalDiscovered` Journal -Event and properly structure it for sending to EDDN. - -Please consult [EDDN Schemas README](./README-EDDN-schemas.md) for general -documentation for a schema such as this. - -## Senders -The primary data source for this schema is the ED Journal event -`FSSSignalDiscovered`. - -### Batching -You MUST put several `FSSSignalDiscovered` events to an array `signals` which is key of `message`. Minimum size of -`signals` is 1 item. - -Do not make a request for every single event. - -Possible algorithm of batching: -1. If the event is FSSSignalDiscovered, store it to the temporal list and proceed to next event. -2. If the next event is also FSSSignalDiscovered, repeat 1. -3. If the next event is any other or there is no other event for more than 10 seconds, send the - temporal list in a single message to EDDN. - -### Elisions -You MUST remove the following key/value pairs from the data: - - - `TimeRemaining` key/value pair. - -You MUST refuse to send the whole `FSSSignalDiscovered` event if `USSType` key has `$USS_Type_MissionTarget;` value. - -### Augmentations -#### horizons flag -You SHOULD add this key/value pair, using the value from the `LoadGame` event. - -#### odyssey flag -You SHOULD add this key/value pair, using the value from the `LoadGame` event. - -#### systemName -You SHOULD add a `systemName` string containing the system name from the last `FSDJump`, `CarrierJump`, or `Location` -event There exists problem when you gets `FSSSignalDiscovered` before -`FSDJump`, `CarrierJump`, or `Location` event, so you MUST cross-check it with `SystemAddress` or don't include at all. - -#### StarPos -You SHOULD add a `StarPos` array containing the system co-ordinates from the -last `FSDJump`, `CarrierJump`, or `Location` event. There exists problem when you gets `FSSSignalDiscovered` before -`FSDJump`, `CarrierJump`, or `Location` event, so you MUST cross-check it with `SystemAddress` or don't include at all. - -## Receivers -Receivers should remember: `horizons`, `odyssey`, `systemName`, `StarPos` are optional key/value pairs, it means you -should not rely on it will appear in every EDDN event. - -## Examples -This is a few example of messages that passes current `FSSSignalDiscovered` schema. -1. A message without `horizons`, `odyssey`, `systemName`, `StarPos` fields. -```json -{ - "$schemaRef":"https://eddn.edcd.io/schemas/fsssignaldiscovered/1", - "header":{ - "gatewayTimestamp":"2021-11-06T22:48:43.483147Z", - "softwareName":"an software", - "softwareVersion":"a version", - "uploaderID":"an uploader" - }, - "message":{ - "event":"FSSSignalDiscovered", - "signals":[ - { - "timestamp":"2021-07-30T19:03:08Z", - "event":"FSSSignalDiscovered", - "SystemAddress":1774711381, - "SignalName":"EXPLORER-CLASS X2X-74M", - "IsStation":true - } - ] - } -} -``` - -2. A message with `horizons`, `odyssey`, `systemName`, `StarPos` fields which says it sent from Odyssey. -```json -{ - "$schemaRef":"https://eddn.edcd.io/schemas/fsssignaldiscovered/1", - "header":{ - "gatewayTimestamp":"2021-11-06T22:48:43.483147Z", - "softwareName":"an software", - "softwareVersion":"a version", - "uploaderID":"an uploader" - }, - "message":{ - "event":"FSSSignalDiscovered", - "signals":[ - { - "timestamp":"2021-07-30T19:03:08Z", - "event":"FSSSignalDiscovered", - "SystemAddress":1774711381, - "SignalName":"EXPLORER-CLASS X2X-74M", - "IsStation":true - }, - { - "timestamp":"2020-12-31T14:14:01Z", - "event":"FSSSignalDiscovered", - "SystemAddress":216054883492, - "SignalName":"$USS_NonHumanSignalSource;", - "USSType":"$USS_Type_NonHuman;", - "SpawningState":"$FactionState_None;", - "SpawningFaction":"$faction_none;", - "ThreatLevel":5 - } - ], - "StarPos": [ - 8.1875, - 124.21875, - -38.5 - ], - "StarSystem": "HIP 56186", - "horizons": true, - "odyssey": true - } -} -``` +# EDDN FSSSignalDiscovered Schema + +## Introduction +Here we document how to take data from an ED `FSSSignalDiscovered` Journal +Event and properly structure it for sending to EDDN. + +Please consult [EDDN Schemas README](./README-EDDN-schemas.md) for general +documentation for a schema such as this. + +## Senders +The only data source for this schema is the ED Journal event +`FSSSignalDiscovered`. + +### Batching +You MUST coalesce contiguouys runs of `FSSSignalDiscovered` events into a +single `signals` array in the message. Minimum size of `signals` is 1 item. + +Do not make a request for every single event other than where they occur +singly (such as when a player utilises the FSS to zoom into USS individually). + +Suggested algorithm for batching: + +1. You will need to track the current location from `Location`, `FSDJump` and + `CarrierJump` events. This is in order to add the top-level augmentation + of `StarSystem` (system name) and `StarPos`. You will need to record: + 1. `SystemAddress` - for cross-checking. + 2. `StarSystem` - name of the star system. + 3. `StarPos` - the galactic co-ordinates of the system. +2. If the event is `FSSSignalDiscovered`, store it to the temporal list. +3. If the event is any other, then: + 1. check if it is `Location`, `FSDJump` or `CarrierJump` - if so you should + use this new location in the message. + 2. If it is not one of those events then you should use the tracked + location from the prior such event. + + Now construct the full `fsssignaldiscovered` schema message using the + tracked location and the stored list of events. *You **MUST** check that + the `SystemAddress` for each `FSSSignalDiscovered` event matches the + tracked location.* If there is a mis-match then drop that event. +4. Each batch of signals will be contiguous and thus should have the same + timestamp, perhaps +/- 1 second at the ends. As such you only need one + single `timestamp` in the `message` and should use that of the first event + you include. + +Point 3i/ii above are because in the current (3.8.0.406) Horizons client the +`FSSSignalDiscovered` events arrive after `Location`/`FSDJump`/`CarrierJump`, +but in the current (4.0.0.1302) Odyssey client they arrive before such events. + +Thus, in Horizons you use the last-tracked location, but in Odyssey you use +the "just arrived" location. + +Manually FSS-scanned USS type signals will come in one by one, possibly with +other events between them (such as `Music` due to zooming in/out in FSS). +There is no need to attempt batching these together if separated by other +events, even though you'll be using the `timestamp` of the first on the +message, despite the actual time-line being dependent on how quickly the +player scans them. + +This batching is more concerned with not causing an EDDN message per event +upon entry into a system. + +### Elisions +You MUST remove the following key/value pairs from the data: + + - `TimeRemaining` key/value pair (will be present on USS). This has a slight + PII nature and is also very ephemeral. + +You MUST drop the whole `FSSSignalDiscovered` event if `USSType` key +has `$USS_Type_MissionTarget;` value. Only the Cmdr with the mission has any +use of these. There's not even a statistical use. + +### Augmentations +#### horizons flag +You SHOULD add this key/value pair, using the value from the `LoadGame` event. + +#### odyssey flag +You SHOULD add this key/value pair, using the value from the `LoadGame` event. + +#### StarSystem +You **MUST** add a `StarSystem` string containing the system name from the last +tracked location. You **MUST** cross-check each `FSSSignalDiscovered` +->`SystemAddress` value to ensure it matches. If it does not, you **MUST** +drop the event. + +#### StarPos +You **MUST** add a `StarPos` array containing the system co-ordinates from the +tracked location. You **MUST** cross-check each `FSSSignalDiscovered` +->`SystemAddress` value to ensure it matches. If it does not, you **MUST** +drop the event. + +## Receivers +### Augmentations are 'SHOULD', not 'MUST' +Receivers should remember that `horizons`, `odyssey`, `StarSystem`, `StarPos` +are optional key/value pairs. You **SHOULD NOT** rely on them being present +in any given event. + +### Duplicate messages from 'busy' systems +When a system is particularly full of signals, such as when many Fleet Carriers +are present, it has been observed that the game repeats the identical +sequence of `FSSSignalDiscovered` events. So you might receive what looks like +a duplicate message, other than the timestamp (if the timestamp is the same +then the EDDN Relay should drop the duplicate). + +## Examples +This is a few example of messages that passes current `FSSSignalDiscovered` schema. +1. A message without `horizons` or `odyssey` augmentations. +```json +{ + "$schemaRef":"https://eddn.edcd.io/schemas/fsssignaldiscovered/1", + "header":{ + "gatewayTimestamp":"2021-11-06T22:48:43.483147Z", + "softwareName":"a software", + "softwareVersion":"a version", + "uploaderID":"an uploader" + }, + "message":{ + "timestamp":"2021-11-06T22:48:42Z", + "event":"FSSSignalDiscovered", + "SystemAddress":1774711381, + "signals":[ + { + "SignalName":"EXPLORER-CLASS X2X-74M", + "IsStation":true + } + ], + "StarSystem":"HR 1185", + "StarPos": [ + -64.66, -148.94, -330.41 + ] + } +} +``` + +2. A message with `horizons`, `odyssey`, `systemName`, `StarPos` fields which says it sent from Odyssey. +```json +{ + "$schemaRef":"https://eddn.edcd.io/schemas/fsssignaldiscovered/1", + "header":{ + "gatewayTimestamp":"2021-11-06T22:48:43.483147Z", + "softwareName":"a software", + "softwareVersion":"a version", + "uploaderID":"an uploader" + }, + "message":{ + "timestamp":"2021-11-06T22:48:42Z", + "event":"FSSSignalDiscovered", + "SystemAddress":1350507186531, + "signals":[ + { + "event":"FSSSignalDiscovered", + "SignalName":"EXPLORER-CLASS X2X-74M", + "IsStation":true + }, + { + "event":"FSSSignalDiscovered", + "SignalName":"$USS_NonHumanSignalSource;", + "USSType":"$USS_Type_NonHuman;", + "SpawningState":"$FactionState_None;", + "SpawningFaction":"$faction_none;", + "ThreatLevel":5 + } + ], + "StarPos": [ + 8.1875, + 124.21875, + -38.5 + ], + "StarSystem": "HIP 56186", + "horizons": true, + "odyssey": true + } +} +``` From d33c752c36ffaf76ef68c991489c1e6ed1dd5510 Mon Sep 17 00:00:00 2001 From: Athanasius Date: Tue, 14 Jun 2022 14:03:49 +0100 Subject: [PATCH 3/6] schemas/fsssignaldiscovered: README: Remove timestamp/SystemAddress from each signal --- schemas/fsssignaldiscovered-README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/schemas/fsssignaldiscovered-README.md b/schemas/fsssignaldiscovered-README.md index 6665b22..f5432dd 100644 --- a/schemas/fsssignaldiscovered-README.md +++ b/schemas/fsssignaldiscovered-README.md @@ -69,6 +69,9 @@ You MUST drop the whole `FSSSignalDiscovered` event if `USSType` key has `$USS_Type_MissionTarget;` value. Only the Cmdr with the mission has any use of these. There's not even a statistical use. +Because we only have a `message` level `timestamp` and `SystemAddress` these +should be removed from each member of the `signals` array. + ### Augmentations #### horizons flag You SHOULD add this key/value pair, using the value from the `LoadGame` event. From 3dbfd181886f32c8c81aebf3d51460188fbe6f54 Mon Sep 17 00:00:00 2001 From: Athanasius Date: Wed, 15 Jun 2022 11:52:25 +0100 Subject: [PATCH 4/6] schemas/fsssignaldiscovered: Rework for per-signal timestamp & misc. clarifications * Per-signal `timestamp` due to the nature of USS signals. * Keeping `message`->`timestamp` so any Listener relying on it being there isn't tripped up (it's present in all other schemas). * Specifiy that each `signals` member should have `event` key/value pair removed. * Mandate removal of `SystemAddress` from each `signals` member. * Receivers: Only `horizons` and `odyssey` augmentations are optional. * Updated examples for these changes. --- schemas/fsssignaldiscovered-README.md | 35 ++++++++++++++++++--------- schemas/fsssignaldiscovered-v1.0.json | 7 +++++- 2 files changed, 29 insertions(+), 13 deletions(-) diff --git a/schemas/fsssignaldiscovered-README.md b/schemas/fsssignaldiscovered-README.md index f5432dd..ddbb9aa 100644 --- a/schemas/fsssignaldiscovered-README.md +++ b/schemas/fsssignaldiscovered-README.md @@ -12,11 +12,12 @@ The only data source for this schema is the ED Journal event `FSSSignalDiscovered`. ### Batching -You MUST coalesce contiguouys runs of `FSSSignalDiscovered` events into a +You MUST coalesce contiguous runs of `FSSSignalDiscovered` events into a single `signals` array in the message. Minimum size of `signals` is 1 item. Do not make a request for every single event other than where they occur -singly (such as when a player utilises the FSS to zoom into USS individually). +singly (such as when a player utilises the FSS to zoom into USS individually, +if there is a different following event). Suggested algorithm for batching: @@ -29,18 +30,16 @@ Suggested algorithm for batching: 2. If the event is `FSSSignalDiscovered`, store it to the temporal list. 3. If the event is any other, then: 1. check if it is `Location`, `FSDJump` or `CarrierJump` - if so you should - use this new location in the message. + use this new location in the message for the augmentations. 2. If it is not one of those events then you should use the tracked - location from the prior such event. + location from the prior such event for the augmentations. Now construct the full `fsssignaldiscovered` schema message using the tracked location and the stored list of events. *You **MUST** check that the `SystemAddress` for each `FSSSignalDiscovered` event matches the tracked location.* If there is a mis-match then drop that event. -4. Each batch of signals will be contiguous and thus should have the same - timestamp, perhaps +/- 1 second at the ends. As such you only need one - single `timestamp` in the `message` and should use that of the first event - you include. +4. Use the `timestamp` of the first signal in the batch as the top-level + `timestamp` in the `message` object. Point 3i/ii above are because in the current (3.8.0.406) Horizons client the `FSSSignalDiscovered` events arrive after `Location`/`FSDJump`/`CarrierJump`, @@ -60,6 +59,10 @@ This batching is more concerned with not causing an EDDN message per event upon entry into a system. ### Elisions +Remove the `event` key/pair from each member of the `signals` array. Including +this would be redundant as by definition we're sending `FSSSignalDiscovered` +events on this schema. + You MUST remove the following key/value pairs from the data: - `TimeRemaining` key/value pair (will be present on USS). This has a slight @@ -69,8 +72,13 @@ You MUST drop the whole `FSSSignalDiscovered` event if `USSType` key has `$USS_Type_MissionTarget;` value. Only the Cmdr with the mission has any use of these. There's not even a statistical use. -Because we only have a `message` level `timestamp` and `SystemAddress` these -should be removed from each member of the `signals` array. +Because of the location cross-check the `SystemAddress` is in the top-level +`message` object, and thus you **MUST** remove such from each signal in the +array. + +Do **NOT** remove the `timestamp` from each signal in the array. Whilst these +should be identical for a "just logged in or arrived in system" set of signals, +this is not true of manually FSS scanned USS signals. ### Augmentations #### horizons flag @@ -93,7 +101,7 @@ drop the event. ## Receivers ### Augmentations are 'SHOULD', not 'MUST' -Receivers should remember that `horizons`, `odyssey`, `StarSystem`, `StarPos` +Receivers should remember that `horizons` and `odyssey` augmentations are optional key/value pairs. You **SHOULD NOT** rely on them being present in any given event. @@ -122,6 +130,7 @@ This is a few example of messages that passes current `FSSSignalDiscovered` sche "SystemAddress":1774711381, "signals":[ { + "timestamp":"2021-11-06T22:48:42Z", "SignalName":"EXPLORER-CLASS X2X-74M", "IsStation":true } @@ -150,11 +159,13 @@ This is a few example of messages that passes current `FSSSignalDiscovered` sche "SystemAddress":1350507186531, "signals":[ { + "timestamp":"2021-11-06T22:48:42Z", "event":"FSSSignalDiscovered", "SignalName":"EXPLORER-CLASS X2X-74M", "IsStation":true }, - { + { + "timestamp":"2021-11-06T22:48:42Z", "event":"FSSSignalDiscovered", "SignalName":"$USS_NonHumanSignalSource;", "USSType":"$USS_Type_NonHuman;", diff --git a/schemas/fsssignaldiscovered-v1.0.json b/schemas/fsssignaldiscovered-v1.0.json index f649e2f..2664989 100644 --- a/schemas/fsssignaldiscovered-v1.0.json +++ b/schemas/fsssignaldiscovered-v1.0.json @@ -49,7 +49,8 @@ }, "timestamp": { "type" : "string", - "format" : "date-time" + "format" : "date-time", + "description" : "Duplicate of the first signal's timestamp, for commonality with other schemas." }, "SystemAddress": { "type": "integer" @@ -63,6 +64,10 @@ "required": ["SignalName"], "description": "Single FSSSignalDiscovered event", "properties": { + "timestamp": { + "type" : "string", + "format" : "date-time" + }, "SignalName": { "type": "string" }, "IsStation": { "type": "boolean" }, "USSType": { From 5d945297e14572531e2a7113d5920096d2de154d Mon Sep 17 00:00:00 2001 From: Athanasius Date: Wed, 15 Jun 2022 12:42:53 +0100 Subject: [PATCH 5/6] schemas/fsssignaldiscovered: `timestamp` required per signal --- schemas/fsssignaldiscovered-v1.0.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/schemas/fsssignaldiscovered-v1.0.json b/schemas/fsssignaldiscovered-v1.0.json index 2664989..18f8fef 100644 --- a/schemas/fsssignaldiscovered-v1.0.json +++ b/schemas/fsssignaldiscovered-v1.0.json @@ -61,7 +61,7 @@ "minItems": 1, "items": { "type": "object", - "required": ["SignalName"], + "required": ["timestamp", "SignalName"], "description": "Single FSSSignalDiscovered event", "properties": { "timestamp": { From 56b4e20238479251c4dcd2d62d0b48a033ff9d9a Mon Sep 17 00:00:00 2001 From: Athanasius Date: Wed, 15 Jun 2022 14:03:02 +0100 Subject: [PATCH 6/6] Settings.py: Add missing `/` for `fsssignaldiscovered/1` schema --- src/eddn/conf/Settings.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/eddn/conf/Settings.py b/src/eddn/conf/Settings.py index 0b3253a..28e9b21 100644 --- a/src/eddn/conf/Settings.py +++ b/src/eddn/conf/Settings.py @@ -82,8 +82,8 @@ class _Settings(object): "https://eddn.edcd.io/schemas/fssbodysignals/1" : "schemas/fssbodysignals-v1.0.json", "https://eddn.edcd.io/schemas/fssbodysignals/1/test" : "schemas/fssbodysignals-v1.0.json", - "https://eddn.edcd.io/schemasfsssignaldiscovered/1" : "schemas/fsssignaldiscovered-v1.0.json", - "https://eddn.edcd.io/schemasfsssignaldiscovered/1/test" : "schemas/fsssignaldiscovered-v1.0.json", + "https://eddn.edcd.io/schemas/fsssignaldiscovered/1" : "schemas/fsssignaldiscovered-v1.0.json", + "https://eddn.edcd.io/schemas/fsssignaldiscovered/1/test" : "schemas/fsssignaldiscovered-v1.0.json", } GATEWAY_OUTDATED_SCHEMAS = [