search

EDCD / EDDN

EDDN - Elite: Dangerous Data Network
https://eddn.edcd.io/
BSD 3-Clause "New" or "Revised" License
298 stars 59 forks source link

Schemas/CodexEntry: BodyID and Body(Name) ? #145

Closed Athanasius closed 3 years ago

Athanasius commented 3 years ago

LCU No Fool Like One has requested we allow, optinally, BodyID and BodyName through on the codexentry schema. This data won't always be pertinent (there are codex discoverables in space), but where it is, and known, it should be allowed.

This means they'll be 100% optional fields, although we can/will document that senders should (or even must) add them for codex entries on body surfaces.

Is there any way in which, e.g. EDMC, could think a player is on/near a Body, and then the player get into space in range to scan a non-Body item for a codex entry? I'm assuming all such would be too far from any body to feasibly get to without using SuperCruise, and we can 'forget' current body on SC entry, then set them again from SuperCruiseExit/ApproachBody later.

Athanasius commented 3 years ago

FTR: EDMC already records 'current body' name (not ID) on ApproachBody, and forgets it on either SuperCruiseEntry or LeaveBody (going above orbital cruise altitude). So adding that is easy.

BodyID is similarly available in ApproachBody data, so we can also track and add that if available.

Athanasius commented 3 years ago

NB: Despite ApproachBody using Body as the key, we'll use BodyName in the schema, it's less ambiguous.

Athanasius commented 3 years ago

From discussion on Discord:

  1. ApproachBody might be unreliable for Body(Name) when there are closely orbiting binary pairs of planets, i.e. if you clip into the SOI of BodyA, and then go down to BodyB you could still think you're on/near BodyA.
  2. Status.json does contain a Body(Name) if it's applicable, so that could be the more reliable method.
  3. If you scan an Odyssey biological on-foot without having first ship Composition Scanned it, you will get a CodexEntry.
  4. Location logging in on a body on-foot gives both BodyID and Body(Name).
  5. In-taxi you will always be going to a settlement, which means an ApproachSettlement event which has BodyID and BodyName.
  6. We're currently uncertain what happens if you're in a taxi and quickly log out and back in. That's for either "just touched down at destination", or "just got in a taxi you booked from a random point on a body".
NoFoolLikeOne commented 3 years ago

I suppose you could cache the bodyid and bodyName to crosscheck status.json

Athanasius commented 3 years ago

I suppose you could cache the bodyid and bodyName to crosscheck status.json

But the worry is that we'll miss something that should update/clear those, or they'll be wrong.

OK, if Body(Name) from journal events matches with Body(Name) from Status.json then I guess we can trust the BodyID ... but on the other hand you're almost certain to have had a Scan of some sort to match up BodyID and Name before then so you could look up the ID yourself ?

NoFoolLikeOne commented 3 years ago

We only store body data if it has biology of geology so wouldn't be able to do the lookup when getting data from EDDN

robbyxp1 commented 3 years ago

Its sounding too complicated, having to look back in history and double check it. Recipe for different tools to do it different ways.

Athanasius commented 3 years ago

Its sounding too complicated, having to look back in history and double check it. Recipe for different tools to do it different ways.

  1. It won't be required augmentation.
  2. We will document the best practice for adding the field(s).
  3. Listeners are free to ignore those fields, or only trust them from known good senders.
robbyxp1 commented 3 years ago

As discussed,

Add to the description field the rules for adding BodyID/BodyName, such as:

"A codex entry generated between Touchdown and Liftoff should have the BodyID and Body from the touchdown event sent in the BodyID and BodyName field of the schema"

etc

Athanasius commented 3 years ago
  1. Document each schema (starting with this one) properly in a file <schema name>-README.md in the schemas/ directory.
  2. Cite the full public URL to that README in the schema description.
  3. Update the Wiki page to link to each schema and its README.

The README should:

  1. Describe why certain fields are required.
  2. Describe why certain fields are prohibited.
  3. Describe why certain fields are optional.
  4. Describe how to source the data. For most this will simply be "from the relevant journal event as-is". However, for some it will describe keeping track of things like SystemAddress from previous journal events, or pulling the current BodyName out of Status.json.
  5. Describe any caveats for listeners. i.e. CodexEntry might have the BodyName if applicable and there's a chance that game bugs/foibles could cause the wrong body to be cited (i.e. binary planets).
Athanasius commented 3 years ago

From LCU ... if you embark in a taxi and immediately log off, when you log back in you're still in the taxi, and you get a ApproachSettlement event. But as you're still in it you can't possibly trigger a CodexEntry until you disembark the other end.

Athanasius commented 3 years ago

LCU No Fool Like One Canonn R&D: Quit before landing puts you in the taxi and gives approach settlement LCU No Fool Like One Canonn R&D: Quit after landing is the same LCU No Fool Like One Canonn R&D: Logged out on foot in the hanger and got approach settlement followed by Location