Schemas/Journal: FSSAllBodiesFound

[Athanasius]

It is proposed that the FSSAllBodiesFound event be allowed in the Journal schema.

Please discuss any objections, caveats or possible problems with this.

[Tkael]

Augmented with StarPos I'd imagine.

[Athanasius]

As per current policy this events should not be added to the journal schema, but instead to its own schema.

[Athanasius]

Augmented with StarPos I'd imagine.

I'm not actually sure it's needed in this case. There should always have been other events beforehand to give this data for the cited SystemAddress.

@spansh @AnthorNet @clonedArtie any comment ? You're the main consumers of such.

[spansh]

Since we can't guarantee when things arrive in EDDN from the players (some producers retain certain events but not others), I'd always prefer anything referring to a system patched in id64, name and coordinates.

[Athanasius]

Since we can't guarantee when things arrive in EDDN from the players (some producers retain certain events but not others), I'd always prefer anything referring to a system patched in id64, name and coordinates.

I can accept that (and grumble a little as EDMC maintainer, because this always means it's the EDDN sender end that has to do that sort of state tracking).

[robbyxp1]

I can see the use of it, it already carries SystemName, SystemAddress and Count, augment it with StarPos and you get a count of all bodies in a system.

[klightspeed]

FSSAllBodiesFound contains a subset of the information in FSSDiscoveryScan

{ "timestamp":"2021-10-24T10:17:47Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":1, "NonBodyCount":1, "SystemName":"LP 658-2", "SystemAddress":7268024198561 }
{ "timestamp":"2021-10-24T10:17:48Z", "event":"FSSAllBodiesFound", "SystemName":"LP 658-2", "SystemAddress":7268024198561, "Count":1 }

FSSAllBodiesFound also implies "Progress": 1.000000

[Athanasius]

FSSAllBodiesFound contains a subset of the information in FSSDiscoveryScan

{ "timestamp":"2021-10-24T10:17:47Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":1, "NonBodyCount":1, "SystemName":"LP 658-2", "SystemAddress":7268024198561 }
{ "timestamp":"2021-10-24T10:17:48Z", "event":"FSSAllBodiesFound", "SystemName":"LP 658-2", "SystemAddress":7268024198561, "Count":1 }

FSSAllBodiesFound also implies "Progress": 1.000000

I am not going to trust there'll never be a game bug making that untrue. It's harmless to leave in as required by the schema.

[Athanasius]

A naive reading of the latest (v32) Journal documentation would suggest that there's no need for this FSSAllBodiesFound schema, as the actually useful information is the Count field, and that same information should be in FSSDiscoveryScan events, in the BodyCount field.

However, looking back over EDCD Discord to determine why this new schema was proposed at all I've come across some statements from LCU No Fool Like One Canonn R&D:

[ 15:00 ] LCU No Fool Like One Canonn R&D : ScanOrganic and FSSDiscoveryScan are problematic because of fdev bugs.
[ 15:01 ] LCU No Fool Like One Canonn R&D : Both can be generated in the wrong system. ScanOrganic can be thousands of light years from the system it should have appeared in
[ 15:04 ] LCU No Fool Like One Canonn R&D : FSSDiscoveryScan  gets triggered between StartJump and FSDJump as well as after FSDJump.

So, the potential value in this new schema is to have a (more) reliable source for "Total number of bodies in this system".

[Athanasius]

However, it seems likely LCU No Fool Like One had a brainfart, conflating FSSDiscoveryScan (performed manually by a Cmdr using the Discovery Scanner, so definitely after arrival in a system), with FSSSignalDiscovered. The latter can indeed appear in a Journal before the jump to the pertinent system has completed.

[Athanasius]

Thus I'm going to conclude that, given I only opened this issue due to a Discord/EDCD @spansh message citing the event back in July 2021, which is before we added the FSSDiscoveryScan schema, there is no longer any need for this new event/schema, and will close this issue if no-one nay-says that.

[robbyxp1]

{ "timestamp":"2021-12-20T15:37:57Z", "event":"FSSDiscoveryScan", "Progress":0.261145, "BodyCount":6, "NonBodyCount":0, "SystemName":"xdx", "SystemAddress":176274140042027 }

vs

{ "timestamp":"2021-12-20T15:38:47Z", "event":"FSSAllBodiesFound", "SystemName":"xdx", "SystemAddress":176274140042027, "Count":6 }

Seems to be the same..

[Athanasius]

I just did a test in Odyssey 4.0.0.1100:

{ "timestamp":"2022-01-26T16:20:55Z", "event":"Music", "MusicTrack":"DestinationFromHyperspace" }
{ "timestamp":"2022-01-26T16:21:00Z", "event":"Music", "MusicTrack":"Supercruise" }
{ "timestamp":"2022-01-26T16:21:00Z", "event":"Scan", "ScanType":"AutoScan", "BodyName":"Zeta Doradus", "BodyID":0, "StarSystem":"Zeta Doradus", "SystemAddress":44853889387, "DistanceFromArrivalLS":0.000000, "StarType":"F", "Subclass":9, "StellarMass":1.128906, "Radius":745187648.000000, "AbsoluteMagnitude":4.501938, "Age_MY":744, "SurfaceTemperature":6321.000000, "Luminosity":"V", "RotationPeriod":353717.494272, "AxialTilt":0.000000, "WasDiscovered":true, "WasMapped":false }
{ "timestamp":"2022-01-26T16:21:00Z", "event":"FSSAllBodiesFound", "SystemName":"Zeta Doradus", "SystemAddress":44853889387, "Count":1 }

That's a system I didn't have system map data for beforehand, and only has the single star in it, no other bodies.

So, if a Cmdr arrives in a system they didn't already know, which has literally only the arrival star for bodies (or possibly any other body is also close enough to be autoscanned), then FSSAllBodiesFound will fire after the AutoScan(s) and give useful data in the absence of a honk/FSSDiscoveryScan.

[Athanasius]

The docs for this schema should probably allow for:

Senders MAY choose to not send an FSSAllBodiesFound event if they know they have just sent an FSSDiscoveryScan event with Progress == 1.0. But it is not necessary to perform such filtering.

[Athanasius]

This schema is now present in the beta branch is available for testing on the beta service:

Upload: https://beta.eddn.edcd.io:4431/upload/ Listen: tcp://beta.eddn.edcd.io:9510/