Paul Henty

Yes it's completely different. 6020 is an easier way of reading the altitude. 0570 is an 8-byte integer (not a float like 6020) so you'll need to declare it as { name: 'altitude', address: 0x0570, type: 'int', size: 8 }, The conversion to metres/feet is: var altitudeMetres = data.altitude / (65535 * 65535); var altitudeFeet = data.altitude / (65535 * 65535) * 3.28084; Conversion from metres/feet is: var newAltitude = altitudeMetres * (65535 * 65535); var newAltitude = altitudeFeet / 3.28084 * (65535 * 65535); Paul

Heading would be this: var newheading = (plannedrecord.heading / 360) * (65536*65536) Paul

It sounds like it could be working, but just the UI isn't picking up the changes. When you write payload is it affecting the aircraft? In FSX if I write 500kg to the pilot seat the aircraft reacts by sinking down on one side. The names of the payload stations you are getting back are strange though. Especially since they are the same. These are normally say things like "Pilot", "Front Passenger" etc. It does sound like a problem with MSFS or FSUIPC7. Paul

I don't have MSFS so I can't test it here on the aircraft you're using. To track down the problem can you please try: Another MSFS stock aircraft. Using the website example to autoload payload: http://fsuipcwebsockets.paulhenty.com/#cmdpayloadautoload Using this example to load individual payload stations: http://fsuipcwebsockets.paulhenty.com/#cmdpayloadwrite Let me know if any of these work or not, but if they do work then the problem is somewhere in your code. You can examine the code behind the website pages (button at the bottom) to compare to your code. Paul

The website explains and demonstrates how to deal with the values. I recommend going through the offsets examples. The values stored in FSUIPC are encoded into integers. This is mainly for historic reasons regarding how computers used to process data a few decades ago. You need to decode most integer values into real world units. For example your heading value is 1445037629. If you look at the offsets document, it gives the formula for converting to degrees as *360/(65536*65536) for degrees TRUE. 1445037629 * 360 / (65536*65536) = 121.12 degrees true. Note this is not degrees magnetic. To get the magnetic heading to need to subtract the magnetic variation from offset 0x02A0. Latitude and Longitude need a similar conversion, but if you use the 'lat' and 'lon' datatypes instead of 'int' the server will do the conversion for you. You'll get back decimal degrees with no need for further conversion. The offsets document has all the information you need to convert the data from FSUIPC units to human readable units. It's floating point number, so use the type 'float' instead of 'int' and you'll get the proper value. Floating point numbers are used in newer offsets and don't require any further conversion. For the altitude the documentation recommends using 0x6020 (which is a float) instead of 0x0570. For the vertical speed use 0x02C8 instead. The documentation says that 0x030C is just a copy of the VS on touchdown. Using the correct offsets and types will get you most of the way there: offsets: [ { name: 'aircraftName', address: 0x3D00, type: 'string', size: 256 }, { name: 'altitude', address: 0x6020, type: 'float', size: 8 }, { name: 'heading', address: 0x0580, type: 'uint', size: 4 }, {name: 'groundSpeed', address: 0x6030, type: 'float', size: 8}, {name: 'latitude', address: 0x6010, type: 'lat', size: 8}, {name: 'longitude', address: 0x6018, type: 'lon', size: 8}, {name: 'verticalSpeed', address: 0x02C8, type: 'int', size: 4}, {name: 'onGround', address: 0x0366, type: 'int', size: 2} ] You'll still need to manually convert the heading and the vertical speed as described in the offsets document. The website also has an example of this (http://fsuipcwebsockets.paulhenty.com/#cmdoffsetsread. The ground speed is in metres per second so you'll also need to convert that if you want other units like knots or kph. The altitude is in metres so you'll need to convert if you want to see it in feet. Paul

All offset data is stored as integers unless the Offset Status document says they are something else. Whether they are signed or unsigned is sometimes mentioned, but if not it should be obvious. e.g. A heading would be unsigned because you can't have a negative heading. Vertical speed would be signed because you can be going up or down. The other common type you'll see is the floating point number. The document will always tell you if the data is in floating point format; usually it will say FLOAT32 or FLOAT64. There can also be strings. These are usually obvious (e.g. aircraft name) but where not, the documentation will say it's a string. The websocket server also has additional types to make it easer to work with certain offsets: lon and lat for offsets holding Longitude or Latitude values. This avoids a very tedious conversion between Flight Sim coordinates and Degrees bits for offsets where each bit represents a different system. An example is the lights offset 0x0D0C where each bit is a different light. The documentation will make it clear what each bit represents. There is an example of this on the website. Paul

If you just want something automatic that runs as soon as you start the script, then yes you would do both in the onopen function. First send the the declare request, then the read request. Set the 'interval' property of the 'read' request to a number of milliseconds to get automatic (repeating) data updates. Paul

The error message is being produced by the switch statement in the ws.onmessage() function: switch (response.command) { case "about.read": console.log(response.data) break; default: // Unhandled command console.log("Unknown command: " + response.command); break; } You're not handling the "offsets.declare" response. Only "about.read". You can do one of two things: Option 1: Add a case statement for "offsets.declare" and all other commands you are using. In the website example for reading offsets, the successful response from the 'declare' just posts a message to the screen: http://fsuipcwebsockets.paulhenty.com/js/cmdoffsetsread.js switch (response.command) { case 'offsets.declare': document.getElementById('successMessage').innerText = 'Offsets "' + response.name + '" have been declared'; break; case "offsets.stop": document.getElementById('successMessage').innerText = 'Updates for "' + response.name + '" have been stopped'; break; case 'offsets.read': switch (response.name) { case 'myOffsets': showOffsetValues(response); break; } break; default: // Unhandled command document.getElementById('errorMessage').innerText = 'Unknown command: ' + response.command; break; } Option 2: You might find it easier to just delete the 'default' case if you don't want to handle every type of incoming message. Paul

That's very strange. Is this happening on the actual website, or have you copied the code to your own website/program? Also are you using version 0.3.1 of the WebSocketServer? Paul

Not for FSUIPC versions before 7. This is just how it works and isn't going to change now as development is closed on most of the FSUIPC versions. For FSUIPC7 the new MSFSVaraibleServices can read many LVars very quickly via the WASM module. This doesn't use WideFS but uses a SimConnect connection. So on remote machines you just set up a remote SimConnect connection. Yes, just check the property called FSUIPCConnection.IsConnectedToWideClient The value is already put into a free offset by FSUIPC (0x66F8). The issue is that WideFS doesn't transmit this to the WideClient until a few milliseconds after the LVar request is made. This means a second process call must be made to get the value. When running on the FS machine the value is available in the same Process() call. No. The easiest solution is to detect WideFS and use the slower method of access posted above (basically, a second process call to get the data). For FSUIPC3-6 the only true workarounds would be: 1. A Lua Plugin that runs in FSUIPC on the FS machine which reads read the lights etc. from whatever LVars you need to and places the values into free offsets. Then your application reads from the offsets. This would require users to have registered FSUIPC and install the Lua plugin. 2. Write your own 'server' program that always runs on the FS machine that reads the LVars. Then either use the offset method like for Lua, or set up your own TCP/IP communication to read the values directly from your server program. Paul

The PayloadServices class just uses the normal FSUIPC payload station offsets (starting at 0x1400). If FSUIPC cannot get the information then PayloadService will also not see it. Paul

I've found that bug. Please try 0.3.1 - you shouldn't get that particular crash any more. http://fsuipcwebsockets.paulhenty.com/#home Yes it was working then. If there was no connection it would have reported a "NoFlightSim" error. For your connection problem - it sounds like something in the WASM module. The log entries are directly from that module, so not part of my software. To check, please try John's WASMClient.exe which can be found in the "FSUIPC WASM Module 0.5.4" package available at http://fsuipc.com/ If that also fails to connect then you'll need to ask John Dowson about it. It could be that the other WASM module has messed something up. If his client does work then let me know and I'll look into it more on my side. Paul

It looks like John has fixed the problem. Please overwrite your FSUIPC_WAPID.DLL with the one attached. It should work as expected. Paul FSUIPC_WAPID.dll

Yes I can see that here as well. My DLL is just returning the value from the WASM module which seems to be wrong. I've asked John to take a look at this. Paul

Version 0.3.0 is now available on the website. http://fsuipcwebsockets.paulhenty.com/ The zip now contains an extra file FSUIPC_WAPID.DLL which must also be present in the folder you run the server from. The new MSFS Variables feature has its own page in the main form. This shows you the status of the connection to John Dowson's WASM module and allows you to see logging information and list known variables. From the client, access to the MSFS variables (LVars and HVars) is done through the 'vars' command. I've made it work almost identically to the offsets commands for consistency. Once difference is that to write variables, they don't need to be included in any 'declare' first. Any variable can be written at any time. This means the 'vars.write' will not send back a 'read' as it's not tied into a group of variables. In theory calculator code can be run with 'vars.calc' but I've no examples here to try. Full documentation is on the website along with working example code. Paul

I have the MSFS LVar and HVars working in the socket server. Just need to finish the documentation and do a final test. If all goes well I'll release it tomorrow. Paul

First declare yourself a new instance of PMDG_737_NGX_Offsets. Best to do this at the form or module level so you have access to it throughout the code: Private pmdgOffsets As PMDG_737_NGX_Offsets = New PMDG_737_NGX_Offsets() Then when you need the values you call RefreshData() and then access the offsets you want: (You'll need an open connection). pmdgOffsets.RefreshData() ' Get the latest values for the offsets ' Each value is just an offset declared with the correct type. Dim ltsPos As Byte = pmdgOffsets.LTS_PositionSw.Value MessageBox.Show("LTS_Position = " & ltsPos.ToString()) Paul

Hi Allan, I think the only way to set HVars is via the WASM module, so it wouldn't be possible with the SocketServer at the moment. My FSUIPCClient DLL (used by the socket server) now has support for accessing LVars/HVars directly from the WASM module. It seems to be stable now so next week I will expose this via the Socket Server. This will mean you won't need to assign LVars to offsets anymore. You'll have direct access to them with something like "lvar.request". You'll also be able to set HVars and execute calculator code. This will only be for MSFS/FSUIPC7. Paul

You can achieve the same thing by using the same event handler for all the LVars you want to monitor. The eventargs (e) will tell you which LVar has changed... Something like this: this.lVarListen1 = this.VS.LVars["A32NX_ADIRS_KNOB_1"]; this.lVarListen1.OnValueChanged += lVar_OnValueChanged; this.lVarListen2 = this.VS.LVars["A32NX_ADIRS_KNOB_2"]; this.lVarListen2.OnValueChanged += lVar_OnValueChanged; private void lVar_OnValueChanged(object sender, LVarEvent e) { // One of your LVars has changed. // The changed one is e.LVar Log(e.LVar.Name + " has changed to " + e.Lvar.Value.ToString("F4"); } Will that do what you want? Paul

1 - A new version of the DLL is now on NuGet - 3.2.10 The MSFSVariableServices has had some changes to make it work better. Unfortunately most are breaking changes but they're not that drastic: The VariablesReady property has been removed as that never really worked after it was initially set to true. The OnVariablesReadyChanged event has been replaced with OnVariableListChanged. This fires whenever the WASM module detects new LVars or HVars. You can use this to know when the variables have been detected and are ready to read. 2 - Example Code / Test Project I've added an example project for the MSFSVariableServices to the website: http://fsuipc.paulhenty.com/#downloads C# only at the moment. I'll convert to VB.NET if anyone requests it. 3 - Requirements This new version should be used with version 0.5.3 of the FSUIPC_WAPID.dll or later. Also required is FSUIPC7 V7.2.7 (or later) as this will install the 0.5.3 WASM module into MSFS. Both can be download from http://fsuipc.com/ 4 - Access Violations in CRJ This may or not be fixed with this version. John has increased the number of LVars that can be handled in 0.5.3 which might have have been the problem. Paul

Hi, The equivalent in VB.NET would be: Dim flapStatus As Double = FSUIPCConnection.ReadLVar("L:VC_PED_FLAP_LEVER") Paul

Hi, Yes, another use above has the same issue with a CRJ aircraft. I assume it's Aerosoft. I think it's something to do with the high number of variable this aircraft has. It was too many for the limits baked into WASM module. I can see in the GitHub project that John has expanded the capacity in version 0.5.3. I'm hoping that will fix the issue. The fsuipc.com page still has 0.5.2 so we'll need to wait until John releases the new version to try it. Paul

Ah, okay that's clear. I'd not heard of .evt files before. In that case you can use my DLL to send the control number (also called Event ID): FSUIPCConnection.SendControlToFS(eventID, parameter); Most controls will not take a parameter value, so just pass 0. You'll just need to calculate the ID number as described. So if that's your only .evt file then A320_Neo_MFD_BTN_CSTR_1 will just be control number 32768. A320_Neo_MFD_BTN_WPT_1 = 32769 etc... Paul

I can't really say at the moment because I don't know what these are. I don't know MobiFlight. Are these LVars or HVars that are being triggered somehow? If so you can access them with my FSUIPCClient dll. If these are plain SimConnect events then you'll need to use the SimConnect API rather than FSUIPC. Using the .NET SimConnect wrapper isn't easy however and while there was one for FSX and P3D, I don't know if Asobo have made one for MSFS. If not you'll need to use C++. I have the FBW A320 so I'll have a look at its lvar list and see if I can see that variable. I'll report back later today. Paul

No, but I'm making a simple example project. I expect it will be ready tomorrow. Paul