Paul Henty

Hi Joe, I've tested the user interface here and I can't get it to throw that exception. Tried lots of reloads, lvar lists, running a client against it for 20mins etc. Does it happen every time you press reload? I also tested changing the Calc Code while it's running. Again no problems at all. I was able to send a new calc message with different code and it just executed the last one. e.g. {command: 'vars.calc',name: 'calc',code: '(L:ParkingBrake_Position) (>L:PJH)', interval: 200} then {command: 'vars.calc',name: 'calc',code: '(L:TAXI_LIGHTING_1) (>L:PJH)', interval: 200} then {command: 'vars.calc',name: 'calc',code: '222 (>L:PJH)', interval: 200} I'm not sure what's going on on your system, but I'm pretty sure the WebSocketServer code is not the problem. Paul

I meant how to reproduce the exception you posted. From the call stack it looks like you pressed one of the buttons on the UI. Can you remember which one? Paul

I'll look at that as well, but I need to know how to reproduce it. The call stack suggests it's after a button press. Which one? Paul

Hi Joe, I'll check this tomorrow and see if I can reproduce the problem. I'll let you know what I find. Paul

Version 3.3.6-beta is now on NuGet. You'll need to tick "Show Pre-Release" in the Nuget package manager to see it. Please try with this version and see if it fixes the exceptions. Paul

HI Nabeel, It looks like a threading issue. It seems like my DLL is receiving simultaneous callbacks from the WASM library on different threads. It nothing to do with your code. John did change the WASM library to automatically report new LVar discoveries about two weeks ago. It could be related to that. I'll add some thread-safety to this part of my DLL tomorrow. Hopefully that will fix it. Paul

I have access to MSFS for a month so I was able to try this here and it seems to work fine. Here is the code I ran in the Chrome console (I just modified yours to copy the parking brake into a custom LVar): function Sleep(milliseconds) { return new Promise(resolve => setTimeout(resolve, milliseconds)); }; let calccode = {command: 'vars.calc',name: 'calc',code: '(L:ParkingBrake_Position) (>L:PJH)', interval: 200} let declare = {command: "vars.declare",name: "myVarSet",changesOnly: true,vars: [{ name: "PJH" }]} let read = {command: "vars.read",name: "myVarSet",changesOnly: true, interval:200} let socket = new WebSocket("ws://localhost:2048/fsuipc/", "fsuipc"); socket.onopen = function(e) { socket.send(JSON.stringify(calccode)); Sleep(200); socket.send(JSON.stringify(declare)); Sleep(200); socket.send(JSON.stringify(read)); }; socket.onmessage = function(event) { console.log(`[message] Data received from server: ${event.data}`); }; socket.onclose = function(event) { if (event.wasClean) { console.log(`[close] Connection closed cleanly, code=${event.code} reason=${event.reason}`); } else { console.log('[close] Connection died'); } }; socket.onerror = function(error) { console.log(`[error] ${error.message}`); }; If I change the parking brake the L:PJH variable gets reported as changed with the correct value. Ran fine for about 10 mins until I stopped it. Maybe you could try the same. If it works, it would suggest the problem is somewhere other than the socket server. Paul

Yes, thanks. That narrows it down a bit. I'll look into it over the next few days and get back to you.

That shouldn't be an issue. My dll detects the reload from the "fsuipcw_registerUpdateCallback" callback. Then it gets the new LVars list and re-registers all for callbacks (-1 parameter). Paul

Can you monitor those LVars (A20N_L_TK_Pump_1_Off and A32NX_OVHD_INTLT_ANN) from somewhere else (e.g. The sim, John's WASM Client) and see if they are changing or not. I need to know if the calculator code is not updating them, or if my server is just not sending them to you. When did you get this? It look like you pressed a button on the UI. Can you rememeber which button? Paul

Hi Peercat, There isn't a DisplayText() method unfortunately. You can display a message on the simulator screen using offsets 0x3380 and 0x32FA. (Both should have the Write-Only parameter set to True). Note however that this isn't working in MSFS (FSUIPC7). It does work in P3D and FSX. 1. Declare the offsets in a group (e.g. "message") private Offset<string> messageWrite = new Offset<string>("message", 0x3380, 128, true); private Offset<short> messageControl = new Offset<short>("message", 0x32FA, true); 2. Send a message string Message = "my message test"; this.messageWrite.Value = Message; this.messageControl.Value = 2; // Display for 2 seconds FSUIPCConnection.Process("message"); See the documentation about 0x32FA for the different values you can send for the messageControl. Paul

I'm not sure how FSUIPC determines if the AI aircraft is airborne or on the ground. My dll just uses the two offsets provided (0xE000 for ground, 0xF000 for airborne). Maybe @John Dowsoncan give you more info about how FSUIPC populates these two areas. Paul

Version 3.3.5 is now on NuGet. After updating you will need to rebuild the database to get the Airlines. Paul

Hi Ruediger, I've just checked my code and it's not saving the airlines in the database. I'll get a new version out tomorrow with this fixed. Paul

The WAPID.dll is dynamically loaded so the compiler can't check it. I have just gone through each function and checked all the signatures (and callback signatures) manually and everything is okay. According to GitHub the .h file hasn't changed for 5 months. There's obviously something behaving differently in the latest WAPID/WASMIF that's causing some issues directly, or causing my use of the WAPID.DLL to be a problem now. King: What version of the FSUIPC_WAPID.DLL were you using before? I think the next step would be to get the logs that John asked for to see if those can shed any light on this. Paul

Hi, Which version of my DLL are you using? The WASM system and the old FSUIPC connection do not interact at all, so I'm not sure that closing the connection is the cause. You should stop the WAPI connection (MSFSVariableServices.Stop()) before you application (and therefore my DLL) gets unloaded. But the WAPI runs independently from the normal FSUIPC Connection and shouldn't be affected by opening/closing it. I can't test here as I don't have MSFS, but here are some suggestions: 1. Post the details of the event log error. @John Dowson might be able to tell the cause of the crash from that. 2. Enable the full logging (TRACE) in MSFSVariableServices. This might give some clues before it crashes. 3. Try running the MSFSVariableServices Example Application. You'll need to update the FSUIPC_WAPID.dll to the same one you're using, and update my DLL to the latest via NuGet. See if that has any problems. If it's fine, try adding code to open and close the normal FSUIPCConnection. Paul

Version 3.3.4 is now on Nuget. FSUIPCConnection.AirportsDatabase.DatabaseFolder is now read/write. Set this property if you want to use a specific path for the internal database files, If you don't set a path it will use the default folder (%localappadata%\FSUIPCClientDLL). Paul

Hi Ruediger, I'm almost certain there won't be any problem with this. Except for the Rebuild(), all the airports database functions open the files as read-only with shared access. However, at the moment the path to the internal database files is fixed and can't be changed (you'll find the DatabaseFolder property is read-only). You'll need this to be writable so you can set it to the folder on your network. I'll make this change and upload a new version in the next few days. Paul

New websocket server is now available (Version 1,1,1): http://fsuipcwebsockets.paulhenty.com/ Uses new WAPI version 1.0.0 beta. vars.calc now has 'interval' property to request repeated execution of calculator code. Time in milliseconds. Stop the repeats with vars.stop command. (Use the same command name). Multiple code requests can be repeated by using unique command names. Paul

Okay - I'll make the changes. I expect to have a new version out sometime next week. I'll also update to the new WAPI library that John is releasing. Paul

Hi Joe, If your calculator code is updating the LVar then it must be run at regular intervals. The only question is *where' it's being run at regular intervals. It seems like you don't want to do it in your code as it will result in a lot of network traffic. Would it help if I enabled the 'interval' property for the 'vars.calc' command? The websocket server would then run the calc for you every x milliseconds. If you monitor the destination LVar with changesonly then you'll just get a message when the destination lvar changes. Let me know if that sounds like a useable solution. But before I do the work, please check that you can indeed write to a new LVar from the calc code and read the resulting value back. Paul

HI Marc, You need to ask John Dowson about this in the main FSUIPC support forum (or the FSCUIP7 MSFS sub-forum if it's for MSFS). Paul

Excellent. I'm happy you got it working. Paul

I've never used Python so I don't think I can help much. However, the response you're getting back is from the connection request: ws = create_connection("ws://MYIP:8384/fsuipc/") Maybe you need to get that response first, then send your 'about' command and get the response from that: import json import websocket from websocket import create_connection websocket.enableTrace(True) ws = create_connection("ws://MYIP:8384/fsuipc/") result = ws.recv() print (result) ws.send(json.dumps({"command":"about.read", "name":"about"})) result = ws.recv() print (result) ws.close() Paul

It's usually because of a mismatch between the application (or Visual Studio if you are debugging) and the sim running 'as administrator'. Either both have to be running 'As admin' or neither. If one is admin and the other is not it will not connect. Note that this is only for FSUIPC programs. The MSFSVariableServices doesn't use FSUIPC so this rule doesn't apply for that. If that doesn't fix it, please give more details like the exception that is thrown. Paul