Paul Henty

These problems are causes by a recent change added to FSUIPC7 to support MSFS2024. As John says above the version number is now delayed until FSUIPC7 knows what sim it's connected to. I'm planning to change the DLL so that the connection will fail if there is no FS version. That is, FSUIPC7 is running, but the sim is not loaded/ready. I think that will avoid the problems and keep the behaviour consistent with older FS versions. If the sim isn't loaded and ready then I don't think the connection should succeed. I don't think there is anything useful that can be done with a connection to FSUIPC7 if it doesn't have a connection to the Flight Sim. To John: This change would mean the Socket Server would not need to be delayed. It would just retry until the flight sim version is reported. Paul

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

Hi Andy, I've checked out those airports and everything looks fine here. I looked at my code that reads the protobuf files and found a couple of problems with the thread safety. My tests here are only on a single thread so maybe that's causing your problems. Can you please try version 3.1.15-beta (now on NuGet) and see if that fixes the problems. You'll need to check the box marked "Include Pre-Release" to see the beta version. If that doesn't help, please can you zip and attach your makerunways output files so I can test with the same data as you? Runways.xml F5.csv R5.csv G5.csv Helipads.csv T5.csv Thanks, Paul

Hi Andy, I can't reproduce this here at the moment. Does this only happen for you at a specific airport, or any airport? If it's one airport do you have third-party scenery at the airport? What sim is this? MSFS2020? Are you using the latest version of my dll? (3.1.13) Paul

Hi, Reports 1 and 4 look like they could be some threading problems. I've uploaded a beta version to NuGet that is more thread safe for you to try. (In the Nuget package manager, Check the box "Include Pre-release" to see it). Report 2 looks to be a bad string coming from the WAPI DLL. I'm not sure what to do about that. Does it happen often? Is it only with one particular aircraft? Report 3 looks to be thrown from your code: (or whatever library is calling my DLL). Method: void SimConnectClient.VS_OnValuesChanged(object sender, EventArgs e) In: libclient-win (Version:2.0.0.0) Paul

This control needs two parameters: the index of the source bus and the index of the circuit you want to connect to. (The 2 and 1 in the example code you posted). I don't think it's possible with FSUIPC to send two parameters to an event. Historically they've only allowed one. There are two alternative options I know of: 1. Use the MSFSVariableServices class to execute the calculator code directly: MSFSVariableServices.ExecuteCalculatorCode("2 1 (>K:2:ELECTRICAL_BUS_TO_CIRCUIT_CONNECTION_TOGGLE)"); There is an example project for getting started with MSFSVariableServices on the website: http://fsuipc.paulhenty.com/#downloads 2. Use the 'presets' feature to execute the calculator code stored in the myevents.txt file. See the "FSUIPC7 for advanced users" pdf and offset 0x7C50. Paul

Thanks for checking. I'll upload this version to the website this evening. Paul

I have attached a beta version of the WebSocketServer below. This should have full support for MSFS2024. I haven't released it properly yet because I've not found anyone that can confirm if it works or not. (I don't have MSFS2024). Boebus can you please try the attached version and let me know if it works or not? Thanks, Paul FSUIPCWebSocketServer_V1.1.3-Beta.zip

I think this is a question for @John Dowson. My DLL just writes the hours to offset 0x023B and minutes to 0x023C regardless of what sim you're connected to. Paul

Hi Rob, I've messaged John about this - he says there is an issue where the WASM module sometimes crashes. There is a FAQ about it here: It might be worth trying with a stock aircraft in MSFS2024 or going through the fix suggested in the above post. Paul

Thanks for all the info. Leave it with me, I'll see if I can sort it out. Paul