Closed NoFoolLikeOne closed 3 years ago
Looking into the logs we can see the Odyssey is sending FSSSignalDiscoveredEvents in between StartJump and FSDJump I believe that EDSM does not set the systemName until it gets the FSDJump event. This means that any FSSSignalDiscovered messages are attributed to the system one is jumping from instead of the one that you are jumping to.
Did you mean EDSM
there, as in it's an issue with our EDSM plugin, or did you mean EDMC
and you're seeing that plugins are being passed 'wrong' state ?
Checking some code.
plugins/eddn.py will be blindly inserting StarSystem
as per the current system into these FSSSignalDiscovered
events, and, yes, in this scenario it will be incorrect. I can add a check that if SystemAddress
is present already in the event and it does not match where we think we currently are then we drop the event as being bad/corrupted.
Sure, I could use that to not add the StarSystem but the EDDN journal schema requires StarSystem
be in the event. To get that correct for this scenario we would have to store the details of last seen StartJump
separately, clear them after an FSDJump
(or possibly other scenarios) and otherwise trust that is correct. I'd much rather just not send the event given this is obviously Frontier's problem at root cause. It's that or we're going to have to change EDDN schemas to no longer require StarSystem
. That would take some discussion though.
FSSSignalDiscovered
isn't valid over EDDN, I was thinking of SAASignalsFound
.
So, @NoFoolLikeOne , where is it you're seeing the 'bad' data?
Unless I'm blind, EDMC doesn't change FSSSignalDiscovered
at all before it's passed to plugin journal_entry()
.
It's not valid over EDDN, so the augmentations in plugins/eddn.py are moot.
As far as EDMS in concerned the systemAddress is always used in priority https://github.com/EDSM-NET/Journal-Events/blob/master/Event.php#L279 So it should not affect it.
Closing this as Anthor seems sure his code will still handle it correctly.
@NoFoolLikeOne prod me if something other than EDSM is potentially affected.
Thanks, Yes I meant EDMC
Please check the Known Issues in case this has already been reported.
Please also check if the issue is covered in our Troubleshooting Guide. It might be something with a known work around, or where a third party (such as EDSM) is causing logging that is harmless.
Please complete the following information:
Describe the bug We noticed that AXCZ reports were being raised for systems that did not have AX CZ.
Looking into the logs we can see the Odyssey is sending FSSSignalDiscoveredEvents in between StartJump and FSDJump I believe that EDSM does not set the systemName until it gets the FSDJump event. This means that any FSSSignalDiscovered messages are attributed to the system one is jumping from instead of the one that you are jumping to.
The SystemAddress is set in the FSS events so it is possible to check that the ID64 does not match the ID64 of the current gamestate or attribute the events to the system in The id64 in the StartJump event
To Reproduce Steps to reproduce the behavior:
Expected behavior Events should be attributed to the correct system
Screenshots If applicable, add screenshots to help explain your problem.
Additional context This should also be raised to Fdev as an issue.