Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,366
  • Joined

  • Days Won

    44

Posts posted by Paul Henty

  1. 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:

    1. Load any flight and be ready to fly
    2. Run the wasm client and select start
    3. Get the value of any LVAR, change the control in the sim and then get the new value. This works okay.
    4. Select stop in the client
    5. Then start again
    6. 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

     

     

  2. Quote

     it looks like that update callbacks don't work once fsuipcw_end() has been called, when used from a WPF app.

    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. 

    Quote

    Does that fit with what FSUIPCClientDLL is doing under the hood?

    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

  3. 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

  4. 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

     

  5. 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 

  6. 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

  7. 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

  8. 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

  9. 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

  10. 4 minutes ago, Dabull said:

    Is the computation for writing to this offset different?

    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

  11. 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

  12. 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:

    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

  13. 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.

    Quote

    I have no clue what a floating point double is

    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

  14. 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

    • Like 1
  15. Quote

    Does all the commands need to be in the ws.onopen function?

    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

  16. 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

  17. Quote

    . any improvement on the issue? 

    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.

    Quote

    , is there any way to detect if the user runs widefs?

    Yes, just check the property called FSUIPCConnection.IsConnectedToWideClient

    Quote

    is it possible to put that value on a free offset, and then the app goes and reads the value of that offset? Would it also be a workaround instead of slowing down the dll?

    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.

     

    Quote

    Would it also be a workaround instead of slowing down the dll?

    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

×
×
  • 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.