I have an In-game panel that sets some LVARS that are used in my WASM/SimConnect Standalone Module. The problem I have is, sometimes some of the LVARS that notify me that the toggle has been switched do not make it into the WASM module.
For example, I have an “Open Door” toggle, and I have an LVAR_IS_DOOR_OPEN that is set to “1” when the toggle is on, and to “0” when the toggle is off. However, sometimes the toggle is “toggled”, but the true/false LVAR is not triggered in my WASM/SimConnect module. The logic is sound, but sometimes, the LVAR does not reach my SimConnect module.
I know there is a timing latency between HTML/JS and WASM/SimConnect, and for that purpose I have the LVAR struct update (SimConnect_RequestDataOnSimObject) set up in a main loop at 6Hz rate - I would think plenty of time for the event to be caught. But still, I sometimes get “blank” toggle and button pushes. I temporarily inserted a sound to be played in the region of code that the LVAr is suppose to trigger, just so that I know when the LVAR has actually reached the WASM/SimConnect.
Has anyone have any idea as to how to handle this?
Maybe this is related to the Lvar scope? Since you’re requesting it from a certain simobject. Instead of simconnect, you could also use the VARS API to read/set the Lvars. Or better yet, use the Communication API like tracernz suggested
Thanks @Jayshrike … I don’t think LVAR scope is the problem. LVARS are accessible throughout the server and clients. The problem is that, as I set the LVAR in HTML/JS client, it is SOMETIMES not picked up by my SimConnect/WASM client.
can you clarify the code sequence in the JS vs the WASM ? I.e. are you setting and resetting L: vars in the HTML/JS but aiming for that to be slow enough that the WASM would notice the var going to 1? Or are you settings an L: var to 1 and leaving it there, and the change never makes it through to WASM ?
I have L: vars and Z: vars being set/reset as my go-to “works in all MSFS subsystems” method of propagating a simple event where there is a single intended handler for the event. Numerical variable read/write is the only common denominator across the MSFS 2024 programming languages/API subsystems. The compatibility matrix of publish / subscribe of K:, B:, commbus events across Controls Settings (assign K: only?) and the 6 main languages / API systems isn’t documented but I’m guessing RPN is the poor relation (K: B: publish only?).
HTML/JS is very good at catching the built-in MSFS keybinds configurable in Controls Settings, so if I need that event in RPN I will use a non-UI JS gauge to subscribe to the keybind and set a custom simvar to 1 when that event is detected. The RPN will detect the simvar going to 1, do what it wants to do based on that event, and reset the simvar to 0. I actually use L: and Z: vars but the principle’s the same. This method has the magical effect that players can use MSFS keybinds assigned to controller buttons simply using the stock MSFS Controls Settings, a simple example in gliding is the common “trigger trim” support. In practice it’s best to collect all the given aircraft keybind/simvar mappings into a single non-UI JS gauge, a family of planes (e.g. gliders) can use common mappings. I don’t think it’s reasonable to expect Asobo to create a unique assignable Controls Setting keybind for everything you could possibly want to do in any type of plane, and the B: vars are only partially supported in the sim and not assignable in Controls Settings.