Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review if StarPos should be a top-level mandatory property #176

Open
Athanasius opened this issue Jan 27, 2022 · 0 comments
Open

Review if StarPos should be a top-level mandatory property #176

Athanasius opened this issue Jan 27, 2022 · 0 comments

Comments

@Athanasius
Copy link
Contributor

I'm mostly here thinking about documenting it, in the general schemas README, as a mandatory augmentation for any event/schema where we can reasonably expect the data to be available.

I'm assuming listeners always want this in case they only get, e.g. an ApproachSettlement EDDN message (sender might have had issues with things like FSDJump, or maybe this listener restarted and only caught the in-system events).

Whilst it might be tempting to say "Always add StarPos if you have SystemAddress" I can also see listeners wanting SystemAddress adding if not already present. In general the senders should be able to always remember this from one of Location, FSDJump, CarrierJump, Docked events.

NB: Possible exception needs to be made for where data can be CAPI-sourced, so these augmentations so far as the top-level documentation is concerned may well need to be optional. event/schema-specific documentation may make them individually mandatory if that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant