Paul Henty

Hi Peter, I don't know what could be causing this. It's working here with FSX/Windows 10. Sometimes third-party add-on aircraft don't use the standard FSX data for radios and fuel, but I see you've tried many aircraft. I assume that includes the default aircraft. Could you please enable the IPC Read and IPC Write logging in the Logging tab of FSUIPC. Then try the Fuel and radios again, shut down the sim and paste the log here. The log will be called FSUIPC4.Log in the Modules folder under the main FSX folder. That might give me some clues. Paul

I don't know sorry. I can only suggest trying to set them with John's WASMClient.exe (from the FSUIPC WASM Module 0.5.5a.zip on fsuipc.com). If it doesn't work from there either then maybe ask John about it in the FSUIPC7/MSFS forum. If FBW have a support forum you might try asking there as well. Paul

In my library the WAPI access is independent of the FSUIPC SDK. It can be used without a connection to FSUIPC. That's using FSUIPC/WideFS so nothing to do with SimConnect on the client machine. Do you mean this works on the remote (Client) PC or the MSFS PC? I think this is to select different connections set up within the SimConnect configuration file. So in the SimConnect file you can have a local connection (0) and a remote connection (1).

The OP is wanting to use the WAPID.DLL (via my DLL) on a second machine, talking to the LVars WASM module on the MSFS PC. Am I right in thinking that's just SimConnect and doesn't use FSUIPC? Paul

I can't help with this unfortunately as I've never done this myself. It might be better to ask in the FSUIPC7/MSFS sub-forum. John Dowson might know how to do this. Paul

Hi Marc, You've declared these an standard read/write offsets (WriteOnly set to false). They will only send values if the value you sent is different from the current value (at last process()). If you want to send these values even if the current values are the same, you need to make them WriteOnly (set last boolean parameter to true). That way the offsets will write the value on every process. You won't be able to monitor the values with these offsets however. If you do want to monitor them and only send the values only when you detect a pause or different sim rate then leave them as read/write, but note that the DLL won't bother to write the values that haven't changed. e.g. if the user pauses, it won't send the simrate or slew mode. Earlier versions of the DLL did behave slightly differently in this regard, but it didn't really work properly so I had to fix it. I suspect you wrote this feature using one of those earlier versions and you're now seeing a different behaviour. Paul

Sorry about that. Now corrected. Paul

There should be a section on the download page for "MSFSVariableServices Example Code". Expanding that, you should see buttons for the C# and VB download. If not, press [CTRL-F5] for force the browser to download the new version of the page. It may be using a cached version. Paul

You're welcome. Thanks for the donation. Very kind of you. Paul

VB.NET solution is now available for download on the website: http://fsuipc.paulhenty.com/#downloads Paul

Okay - I'll be able to sort this out tomorrow. I'll post here when it's available. Paul

Thanks John. Is this fix just in the client-side libraries or does the WASM module also need replacing? Paul

Hi John, One of my users reported problems with the MSFSVariableServices not working after stopping and restarting. I've confirmed this but then found it also happens with your client exe. This is for WASM Module 0.5.5. with the DLL and client from the 0.5.5 zip file. To reproduce the problem: Load any flight and be ready to fly Run the wasm client and select start Get the value of any LVAR, change the control in the sim and then get the new value. This works okay. Select stop in the client Then start again Get the value of the lvar again. Change the control in the sim. Get the LVar value again. This time it hasn't changed and gives the same value as before. There are wasm logs in the original thread if you want to see (linked below), but basically after restarting the log just repeats [TRACE]: Config data requested... Paul

I've tested it here and I see the same behaviour. Interestingly it was also with Winforms. I checked John's client program and it's also doing the same thing, so the problem is somewhere on John's end. I'll report this in the MSFS sub-forum. Paul

Yes, that looks to be the problem. From the logs you have posted it looks like the cause of this is the WASMIF module not receiving the simconnect data from the WASM module after end() has been called. The LVARS you get are probably cached from before. I'm guessing the values won't be updated. Yes, my DLL relies only on the callbacks so everything is even driven. The mystery is still why this is different in WPF. I'll get month of MSFS so I can test it here and do some debugging and step through Johns DLLs and Libs. I'll report back over the weekend. Paul

The garbage collection is cleaning up the instances of MSFSVariableServices that you nulled, so those errors are to be expected. The failure to connect on a new instance doesn't really give any more information. I notice that the WASM module is now up to 0.5.5. I think it would be worth updating to the latest version. Remember you need to update the FSUIPC_WAPID.DLL and the WASM module running in MSFS. The easiest way to get the new WASM module is to install the latest FSUIPC but it can be installed manually from the WASM Zip file. (http://fsuipc.com) Paul

Yes it looks like after the restart the WAPI module isn't receiving any SimConnect messages. Can you try setting your variableServices variable to null after you call stop. That way it'll make a new instance and register everything with the WAPIID.DLL again. If that works then it might narrow the problem down to the client side libraries rather than the WASM module or a simconnect. Paul

This is strange. I can't think of any reason why WPF would be any different than WinForms when calling the DLL. Unfortunately I can't test this here as I don't have MSFS. Have you tried enabling a higher level of logging like DEBUG? It might show something. Paul

Creating multiple instances of MSFSVariableServices isn't going to work unfortunately. This feature relies on John's FSUIPC_WAPID.DLL which only supports one instance of the WASM Client. With hindsight it was a poor design choice on my part to make MSFSVariableServices a normal class. This implies that it can be instantiated multiple times. I should have made it a static class. I might change this in a later version. Or I might think about forking the FSUIPC_WAPID.DLL and amending it so that it can handle multiple WASM Clients. For your application I suggest creating a single instance of MSFSVariableServices in your application and use that same instance in any forms you need to. The easiest way to do this would be through a static class or a static property on your main form if you have one. You can register different listeners inside each form and that will work fine. But the init(), start() and setting update frequencies etc must only be done once for that single instance. You should also remove any listeners you have registered when your forms close. Paul

I'm not sure as I don't use websockets for any real world applications. Could it be a timeout? If you're letting the connection go idle for a while and it disconnects after a set amount of time, this would point to a timeout somewhere (server or client). If it's random when the socket is in use then I'm not sure what could cause this. Does it also happen with the examples on the website? Paul

Offset 3124 is described being 1 byte in the documentation, so it would be impossible to get a value over 255. What's likely happening is that you've declared the offset as being larger (e.g. short or int) and you're getting data from subsequent offsets like the fuel pumps (3125) and view direction (3126) mixed in with the version value. Declare the offset as 'byte' and you should be fine. Paul

Offset 0x0C18 contains the units of measure. I don't know if this is working for FSUIPC7/MSFS yet. The FSUIPC7 spreadsheet has this marked as untested, but you should try and see if it works. This offset is read-only however so you won't be able to change it. I don't think there is any way to change this with FSUIPC. Paul

Yes, the websocket server works with all versions of FSUIPC from 3 and higher. The only thing that doesn't work with versions earlier than 7 is the direct access to LVars (vars.* commands) because this is a new feature for FSUIPC7/MSFS. But Offsets and Payload will work fine with FSUIPC6. Download the server here: http://fsuipcwebsockets.paulhenty.com/ Paul

Float is correct for 0x6010/8 because the data is stored as a float. There is no need to use lon/lat for these anyway because the data is already in decimal degrees. 0x0560/8 have the data stored as integers, so you need to either use the int type and do the conversion yourself, or use lon/lat type and let the server do it for you. You're mixing up two different types of offsets. If you're going to read and write then just use 0x0560/8 with the lon/lat data types. Paul

If you declare the offset as type 'lon' or 'lat' the server will handle all that conversion for you. In that case the units you read and write are just decimal degrees. e.g. 34.5 degrees = 34 degrees 30 minutes. Paul