After today’s latest SU14 beta update (1.35.19.0), the commbus API no longer communicates from WASM → JS. This can be replicated by testing the CommBusAircraft example project, which no longer receives any calls from the registered view listener.
I’ve also tested using the new RegisterCommBusListener event, but that doesn’t work either.
And just to clarify, WASM → WASM and JS → WASM still works as intended, it’s just from WASM → JS that is the issue
Holy Mary!!! This is a BIG issue indeed!!
I remember that you guys had to use it to successfully achieve the A/C ↔ tablet communication on your 737. And I’m going to use the WASM/JS Comm API for the current aircraft I have in development right now (the S340 & S2000 to be precise) so if this keeps broken, I don’t know what to do then.
Sylvain (@FlyingRaccoon), can you please help us in this regard?
Thank you.
Could Xbox possibly be experiencing the same issues? We are finding that on Xbox the features within the PMDG Universal Flight Tablet that utilize the very same communications API are also non-functional. Though it may very well be a coincidence, I think it may be prudent to follow the symptoms.
It seems like the issue was solved on aircraft but broke a lot of things when WASM is loaded as a standalone module.
It appears that registering for an event before loading the flight (while in the main menu) will result in events not working at all, leading me to conclude that event listeners can only be registered while a flight is loaded and that event listeners registered during one flight session don’t carry over to other flight sessions. Rebuilding the WASM module after loading the flight works fine.
Because of this and the fact that independent WASM modules aren’t reloaded for every flight, we tried unregistering and re-registering all event listeners when AircraftLoaded is triggered. This worked fine in SU13 but now it appears that unregistering and then re-registering event listeners doesn’t work anymore when loading into a second flight (restarting the flight works though). Events aren’t flowing through.
Here’s the code I use. I have tried fsCommBusUnregisterAll, fsCommBusUnregister.
There is indeed a problem if you unregister and then register an event in the same frame (same event name, same Wasm Module, same context). This is not related to standalone module. Unfortunately, it cannot be fixed before SU14 release.
It is possible for a standalone module to register itself during its module_init (during the initial boot) and to be called once the event is triggered. There is no limitation about the moment you have to use the fsCommBusRegister function. So, in your code, you don’t need to track the AircraftLoaded event to “refresh” your callback. Registering once should be sufficient.
If you manage to reproduce this behavior, please share it with us so we can investigate.
Is this now resolved for both Xbox and PC, or just PC? We just loaded up our plane in Xbox and it seems the comm bus is still not operational. Currently, we don’t know of a way to get debug info, such as prints and others from within the Xbox, so pinning down the issue is, I don’t want to say, impossible, because “software”, however it is substantially difficult. And without any known way to quickly load the xbox with an edited/updated WASM, it is difficult to get a good workaround for that limitation up and running.
@EPellissier or @FlyingRaccoon do either of you have any suggestions, for how we could go about identifying why it works on PC but not on Xbox ?
The CommBus API works the same on PC and Xbox and has been fixed.
If you still have two different behaviors depending on the platform (using the same code), can you please provide us with your package and your source code so we can investigate, following this article How to report a bug or crash