Jump to content
The simFlight Network Forums

Paul Henty

  • Posts

  • Joined

  • Days Won


Everything posted by Paul Henty

  1. Thanks John. Is this fix just in the client-side libraries or does the WASM module also need replacing? Paul
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. Heading would be this: var newheading = (plannedrecord.heading / 360) * (65536*65536) Paul
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.