mpaperno
MSFS 2024 - WASM Module Connection Issues
Describe the bug For some reason with MSFS 2024, the touch portal plugin is not able to initialize/ connect properly (randomly) on some attempts to use the WASM Module:
02.11 03:27:38.962] [INF] MSFSTouchPortalPlugin.Services.SimConnectService: [WASM] "Client" - Connected to Simulator "SunRise" v12.1.282174.999, with SimConnect v12.1.0.0 (Server v6)
[02.11 03:27:38.963] [INF] MSFSTouchPortalPlugin.Services.SimConnectService: [WASM] "Client" - Connecting to WASimCommander server...
[02.11 03:27:40.464] [ERR] MSFSTouchPortalPlugin.Services.SimConnectService: [WASM] "Client" - Server connection timed out or refused after 1500ms.
[02.11 03:27:40.566] [INF] MSFSTouchPortalPlugin.Services.SimConnectService: [WASM] "Client" - Shutdown complete, network disconnected.
[02.11 03:27:40.566] [WRN] MSFSTouchPortalPlugin.Services.SimConnectService: WASM Server not found or couldn't connect, integration disabled.
[02.11 03:27:46.225] [INF] MSFSTouchPortalPlugin.Configuration.PluginConfig: Loading variable requests from file 'C:\Users\Corry\AppData\Roaming\TouchPortal\misc\GSFENIXA320.ini'...
[02.11 03:27:46.238] [INF] MSFSTouchPortalPlugin.Configuration.PluginConfig: Loaded 272 variable requests from 'C:\Users\Corry\AppData\Roaming\TouchPortal\misc\GSFENIXA320.ini'
[02.11 03:27:46.239] [INF] MSFSTouchPortalPlugin.Services.PluginService: Removing variable request 'GsFenixA320AutoPilotSpeedManagedDot' due to: can not request 'Q' type variable without WASM integration.
The log seems to suggest that the plugin is not able to connect to the WASM module? Note that some percentage of the time, it does work correctly, so I would assume that means my configuration is correct?
To Reproduce Steps to reproduce the behavior:
- I can not seem to reliably reproduce this.
Expected behavior
- when i load ini state file, it is able to utilize sim values to set template switches.
Plugin Version 1.6.0.0
Edit: Further Information
- Restarting TouchPortal iOS app and Windows app does not resolve this when it occurs. This seems to imply the issue is on the WASM Module?
Hi, sorry for the delay in responding but I was traveling.
I'm not really sure what the issue may be since it is intermittent. But it would be good to chase it down.
Which FS 24 version are you running, the current release or SU1 beta?
Does it matter when you try to connect to the sim? Eg. once it boots to the main menu, vs., say, once a flight is launched?
Do you have any other add-ons installed?
Any other clues which could help me reproduce this would be helpful as well (if possible).
Thanks! -Max
Hi, thanks for the reply:
Which FS 24 version are you running, the current release or SU1 beta?
Currently on SU1 beta, but did have the same issue on the base release.
Does it matter when you try to connect to the sim? Eg. once it boots to the main menu, vs., say, once a flight is launched?
There is no discernible pattern that I have noticed on this.
Do you have any other add-ons installed?
Full print of my community dir is in this attached file. comm_dir.txt
Note that I do use a number of addons (including my own) that uses the Mobiflight WASM module (through a Python extention library).
One theory: maybe these can conflict during initialization (such as interweaved initialization of client areas?)
I've enabled logging of server_conf.ini - maybe that will help to log what is going on in WASM module? I have not yet had it occur again since enabling this, but if I get a log I'll post it here.
Ah the intermittent ones are always "fun."
Does the plugin itself ever have trouble connecting?
One thing that comes to mind is the SimConnect.xml MaxClients setting, which is per connection type. Do you know what I mean? The default is 64 and I've read that they're not always released properly if a connection fails (eg. if trying to connect repeatedly while sim is still starting up)... though I've never personally run into this issue. But seeing the number of add-ons you're using, it crossed my mind.
Enabling extended logging in server_conf.ini is a good idea, definitely LMK if that sheds any light on the matter.
Along the same lines there's a corresponding client_conf.ini which can be found in the plugin's dist folder.
Of particular interest may be the networkConfigId setting which is going to dictate which connection type the WASimClient uses to connect to the module/server. The plugin places a default SimConnect.cfg in its root install directory, which defines the config IDs and protocols used. The defaults use the Pipe type connection on Custom/SimConnect port. (And maybe bumping MaxClients in SimConnect.xml for the corresponding type/port may help.)
There is also a networkTimeout setting in there, which by default is 1500 ms. Perhaps bumping that up may help?
Another thought, to try to isolate the issue, is to try connecting to the WASM module using the WASimUI test app (available at https://github.com/mpaperno/WASimCommander/releases -- no installer, just unzip to anywhere and run WASimUI.exe). If the connection fails via plugin but works via the UI, that might provide some clue... perhaps having multiple connection attempts "too rapidly" might be causing some issue? (The plugin connects first though, then tries to connect to WASM module afterwards, so they're not simultaneous.) Seems unlikely but FS24 is such a buggy mess that I wouldn't be entirely surprised.
Although somewhat irrelevant, but do you happen to have FS 20 as well, and if so have you seen any issues connecting to that?
That's all I got for now! :)
"BTW," all the L vars GoodSeb's Fenix A320 pages use can be replaced with more efficient requests for L vars specifically, instead of RPN code. L vars are also supported by SimConnect natively, so no WASM module is even needed for those.
For example (from GSFENIXA320.ini):
[GsFenixA320AutoPilotSpeedManagedDot]
CategoryId = AutoPilot
Name = "FENIXA320_FCU_SPD_MANAGED_DOT"
VariableType = L
SimVarName = "I_FCU_SPEED_MANAGED"
DefaultValue = "0"
(Set VariableType to L, remove (L: and ) from SimVarName, and delete CalcResultType entirely. Also not sure DeltaEpsilon is doing anything useful in this case -- he seems to use that for every variable, even integer types, which just adds more overhead.)
This doesn't fix whatever the underlying issue is with the WASM connection of course, but using RPN to read all those vars is terribly inefficient, so that would be a good change anyway.
PS. And I see some of the requests actually do need RPN (eg. GsFenixA320RMPLeftActiveFreq) so that wouldn't "solve" all the issues anyway.
Does the plugin itself ever have trouble connecting?
In the affected scenario, the IOS app seems to connect. I'm not sure how I can best know if the plugin is connected though? I'm not sure I've seen any evidence that the plugin can't connect?
The template I use is based on a online template that I adapted for my own personal use. It has a "Flight Simulator Connection" button and a "INIT FILE STATE" button which loads the Fenix ini file.
When I do have the issue, these will both show green although when I click the INIT button it seems to randomly cycle all of the values - which makes sense since the log shows the connection to WASimCommander has failed. Behavior on this is exactly the same if I try this when the Simulator hasn't run yet.
One thing that comes to mind is the SimConnect.xml
MaxClientssetting, which is per connection type. Do you know what I mean? The default is 64 and I've read that they're not always released properly if a connection fails (eg. if trying to connect repeatedly while sim is still starting up)... though I've never personally run into this issue. But seeing the number of add-ons you're using, it crossed my mind.
I can certainly try raising this. I looked into the base Python mod that handles a good chunk of my SimConnect connections and it seems to use the pipe connection method as well. If this was the issue though I think I would expect to see more random errors distributed through my various add ons?
Along the same lines there's a corresponding
client_conf.iniwhich can be found in the plugin'sdistfolder.
I now have this log enabled as well.
There is also a
networkTimeoutsetting in there, which by default is 1500 ms. Perhaps bumping that up may help?
Bumped this up to 3000.
Another thought, to try to isolate the issue, is to try connecting to the WASM module using the WASimUI test app (available at https://github.com/mpaperno/WASimCommander/releases -- no installer, just unzip to anywhere and run
WASimUI.exe). If the connection fails via plugin but works via the UI, that might provide some clue... perhaps having multiple connection attempts "too rapidly" might be causing some issue? (The plugin connects first though, then tries to connect to WASM module afterwards, so they're not simultaneous.) Seems unlikely but FS24 is such a buggy mess that I wouldn't be entirely surprised.
Next time I have this issue I will try to connect with this tool and present my findings.
Although somewhat irrelevant, but do you happen to have FS 20 as well, and if so have you seen any issues connecting to that?
I used this same plugin in MSFS 2020 as well and maybe had a couple of random issues with it, but for the most part was good.
Would you like me to raise max clients and the timeout and then report back if I encounter it again?
Thanks again for the reply.
I'm not sure how I can best know if the plugin is connected though?
The "connect" button on the page(s) should show the status properly... and if it wasn't connecting that would be in the plugin's log as well. It will retry if connection fails, but at 30 second intervals, so it should be fairly obvious if that was failing. Sounds like that part is working fine though.
I'm not entirely sure how the "INIT" button is set up to determine that the custom INI file is loaded... but likely based on the value of the LoadedStateConfigFiles ("List of currently loaded state configuration file(s)") plugin State, whether it contains "GSFENIXA320.ini" or not. Which it would if the file was loaded at all, even if the custom states are later removed due to WASM module connection failure.
I looked into the base Python mod that handles a good chunk of my SimConnect connections and it seems to use the pipe connection method as well. If this was the issue though I think I would expect to see more random errors distributed through my various add ons?
Potentially, yes... though it may depend on when those other add-ons make their connections in relation to this plugin + WASimClient/Module. But the fact that the plugin itself seems to connect consistently suggests that's not the issue, since the plugin uses that same pipe connection by default as well (unless you changed it in the plugin's Settings). So, probably not the issue (though raising the limit shouldn't hurt anything either).
There's also a way to enable SimConnect debug logging using SimConnect.ini (in AppData/Local/Packages/Microsoft.Limitless_..../LocalState folder). Not sure if that would tell us anything useful or not.
Would you like me to raise max clients and the timeout and then report back if I encounter it again?
Definitely interested in anything you discover! Also with the extra logging you enabled.
I'm guessing the connection attempt never even reaches the module itself (for whatever reason)... but also possible that the reply (from module/server back to client) gets lost and so the client thinks it never connected. The module's debug logging should tell us that, at least.
The WASimUI app is probably the best bet to debug this stuff, assuming the connection issue can be reproduced there as well. For instance, the app's "Connect" button has a dropdown menu where you can invoke individual stages of the connection -- First stage just inits/opens SimConnect, after which you should be able to "ping" the actual module (server) and/or connect to it as the 2nd stage.
OTOH if it can't be repro'd using the test UI then it's likely related to the combo of plugin + client somehow. I could build a special version of the plugin which separates the connections (plugin's SimConnect vs. the WASimClient to module) into separate TP Actions, to see if giving more time between connection makes a difference.
But I'm getting ahead of myself... let's see what you get in the module/client logs if/when it happens again!
Thanks, -Max
Oh one more question, just to confirm... do you connect the plugin to the sim using one of the "Connect" buttons on a page, or do you have the plugin setup to connect automatically (in TP Settings -> Plug-ins -> MSFS)? If the latter, then do try disabling that and only using a "Connect" button.
The WASimUI app is probably the best bet to debug this stuff, assuming the connection issue can be reproduced there as well. For instance, the app's "Connect" button has a dropdown menu where you can invoke individual stages of the connection -- First stage just inits/opens SimConnect, after which you should be able to "ping" the actual module (server) and/or connect to it as the 2nd stage.
But I'm getting ahead of myself... let's see what you get in the module/client logs if/when it happens again!
Thanks, -Max
Okay, I'll be sure to try connecting with WASimUI app if this issue occurs again for me - thanks!
Oh one more question, just to confirm... do you connect the plugin to the sim using one of the "Connect" buttons on a page, or do you have the plugin setup to connect automatically (in TP Settings -> Plug-ins -> MSFS)? If the latter, then do try disabling that and only using a "Connect" button.
It was set to 1 (automatically connect). I'll set it to 0 and use the connect button.
It was set to 1 (automatically connect). I'll set it to 0 and use the connect button.
Ah, so potentially WASimClient was trying to connect to the module before it was fully initialized (or "paused" for some other unknown reason), but SimConnect server was already activated... so plugin can connect but not the WASM bits.
At any rate, having the connection manually controlled will also make it easier to test. The plugin will (re-)try to connect WASimClient each time it successfully connects to SimConnect, so if the WASM connection fails, disconnecting and re-connecting (using a button) will essentially retry the whole process.
That also gives me an idea that a new TP State indicating WASM connection status might be useful! (Dunno why it took me so long to think of that... :)