Paul Henty

You can use the FSUIPC logging to log the controls being sent. You can make sure the numbers are what you expect. Other than that, I can't suggest anything else unfortunately. I don't have any PMDG aircraft. All my DLL does is send the controls and parameter value via FSUIPC. If it's not working you'll need to ask John or PMDG. Paul

Have you tried sending the direct values instead of the mouse click values? Paul

Yes, that's what's happening. The WebSocketServer uses my DLL and that gets the version information when the connection to FSUIPC is opened. Will 0x3308 be 0 before the SimConnection is made? I could check this in the socket server and retry until I get a proper version number. Paul

I don't think so. The LVars come from the loaded aircraft. Paul

14 is the value for is MSFS2024. I don't think you're using the latest version of the DLL. The puzzling thing is that you say it's working sometimes. Do you mean that you sometimes see "MSFS2024 (VX.X)"? If so are these on the same machine or are these reports from different users? Paul

Which sim are you connected to? If it's MSFS2024 you just need to update to the latest version of the DLL. Paul

Looking at your output, you are getting nothing back from the WASM module at all. When you call Init() the WASM client sends a log message telling you version info and if the WASM SimConnect connection is open or not. You should also expect to see the events OnVariableListChanged and OnValuesChanged being fired, which is also not happening. I suspect it can't find the FSUIPC_WAPID.dll file. Check that this is included in your project and that its property "Copy to output folder" is set to "Copy if newer" or "Copy always". I can't remember if the names come through with the L: on or not. When you're getting variables through you can look at the collection: MSFSVariableServices.LVars.Names to see what LVars it found and their exact names. Paul

I've tried this here using the Key_Press_and_Hold control. It may not do what you're expecting. It doesn't repeat the key until you call the release command. So you don't get the action repeating. You can try it for yourself and see if it does what you're expecting... Just paste this into your code and call. sendKeyHoldToFS - holds the key for the specified HoldTime (in milliseconds) then releases it. sendKeyDownToFS - presses the key down but does not release it. snedKeyUpToFS - releases the key. private void sendKeyHoldToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); // Wait Thread.Sleep(HoldTime); // send the key up SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } private void sendKeyDownToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); } private void sendKeyUpToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } Paul

I'll can a new method for this. Probably SendKeyHoldToFS. You'll be able to specify how long to hold the key for. Would that be suitable or do you need separate key down/up calls and do the timing yourself? Paul

Yes, it's my DLL. To michielsweb: If you're only targeting MSFS2020 or MSFS2024 then you should look at the MSFSVariableServices class. This is way more efficient at dealing with LVARs than the FSUIPC interface. There is a demo project on the website. http://fsuipc.paulhenty.com/#downloads You're exceeding the FSUIPC data limit because you keep declaring a new copy of the offset every time the loop goes round... foreach (string input in simdata_input_pending) { string[] i = input.Split(','); if (i.Length >= 2) { string lvar = i[0].Trim(); if (float.TryParse(i[1].Trim(), out float newValue)) { // Send command to update LVAR Offset<string> setLvar = new Offset<string>(0x0D70, 256); You'll end up with hundred of these, all being processed at the same time which will easily exceed the data limit for FSUIPC. Offsets should only be declared once, usually at the class level, and then reused. I have no immediate plans to make the library async. If you want async behaviour on the Process() call you can create and await a new Task... await Task.Run(() => FSUIPCConnection.Process()); Paul

3.3.15-beta3 is now on NuGet. This should now be pretty solid in terms of thread-safety. Paul

Sure. I can probably get it done tomorrow. Paul

I've have a quick look and there's probably more I can do. The airports collections might not behave well if the same collection is being accessed by two threads at the same time. I'll go through the rest of the airports database code and make any improvements needed. Paul

Please can you try 3.3.15-beta2. I've added thread-safety to the LoadComponents method. Paul

Thanks, I'm pretty sure it's a multi-threading problem. Now the file reading is thread-safe, the problem is manifesting one layer up in the in-memory database code. I'll go through all the database code in the next few days and make it thread-safe. I'll let you know when there's a new version to try. Paul