-
Notifications
You must be signed in to change notification settings - Fork 85
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
Update EDDP monitor into a BGS monitor #177
Labels
6. not up to spec
The expected behaviour per the spec doesn’t match the observed behaviour.
significant work
Just sayin'
Comments
Also revise the monitor name to |
Notes:
|
|
Recategorized since the EDDP monitor is unfit for purpose until this is corrected. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
6. not up to spec
The expected behaviour per the spec doesn’t match the observed behaviour.
significant work
Just sayin'
Observed
(Broken out from issue #97)
EDDI relies on data from http://api.eddp.co, which is not up to date. Faction arrays with active and pending states aren't transmitted or handled appropriately by the server or the client.
Investigation
Faction state changes are handled differently in that they are relayed more or less in real time from the EDDN TCP uplink. Though this is bounced through http://api.eddp.co, faction state changes should continue to remain relatively reliable. See https://github.com/EDSM-NET/EDDN/wiki for how this information is transmitted and EddpMonitor.cs for how EDDI receives the data.
http://api.eddp.co appears to be listening to 'FSDJump' and updating a database of faction states. When a faction state change is detected, the server fires off an update of its own for EDDI users to pick up. This update is currently a text string like
Cross reference with EDCD/EDDP-API#3.
The text was updated successfully, but these errors were encountered: