John Dowson

And what is the issue? If you get a validation error, then your VC++ redistributables probably need updating - see the Invalid Key Problems section of the Installation and Registration guide, John

Could it be a problem with your package.path and package.cpath settings? I am not sure why you are changing these - I have never touched these. Try removing the changes you made to these - it should work with the default settings. But it does seem that the dll is being found. Is this the same luacom.dll that is being loaded in FSUIPC? If you still get issues, can you attach the luacom.dll file you are using and I can try it here, but this will be on Monday or Tuesday.

Take a look at offset 0x3122 - it is bit-oriented: John

There should be a text file called "The 2016 List of FSX and P3D Controls" in your FSUIPC4 documents folder (under your Modules folder). I have also attached it below. John The 2016 List of FSX and P3D Controls.pdf

You are using a very old version of FSUIPC7 (7.3.7). Please update to the latest version, 7.3.24. Only the latest version is supported. This was removed quite some time ago and is no longer used or needed. You should need any "fixes". If you are changing anything, please specify what. Why are you doing this? If you don't want FSUIPC7 to be auto-started, just don't install the auto-start component.

If you want a response from the OP, better to tag them with the @wsixpo syntax (now done!). I don't know much about PM or pmgetweather and the pmwx.dat file, so can't help. See if the OP responds, or maybe ask on the PM forums (presuming there is one!). John

Its now John, Pete retired several years ago, although will still help out occasionally. It should work with all versions of FSUIPC, but the offset definitions (FSUIPC.FSI) have not been updated to include any new MSFS offsets, or remove those no longer in use. If anyone wants to do this and supply a new definitions file, I can add this to the release bundle. Personally I don't see a need for this tool anymore - the FSUIPC offset logging facilities together with the FSUIPC Offset status document should suffice for most uses. Cheers, John

It may be because it is under your windows Desktop folder. which has certain restrictions. Try moving it to a non-windows protected folder. If WideClient is installed there, also move that to a new location. Is the lua script requiring this in the same location? If not, try moving it to the same folder as the lua script.

FYI, these are the pause states that the PAUSE_EX1 event can detect: #define PAUSE_STATE_FLAG_OFF 0 // No Pause #define PAUSE_STATE_FLAG_PAUSE 1 // "full" Pause (sim + traffic + etc...) #define PAUSE_STATE_FLAG_PAUSE_WITH_SOUND 2 // FSX Legacy Pause (not used anymore) #define PAUSE_STATE_FLAG_ACTIVE_PAUSE 4 // Pause was activated using the "Active Pause" Button #define PAUSE_STATE_FLAG_SIM_PAUSE 8 // Pause the player sim but traffic, multi, etc... will still run I think it is the 'Pause with sound' state that Pause Set and Pause Toggle control, which, as it says, is legacy and shouldn't be used...I think I might map these to use Pause On/Off in FSUIPC, although I would still have to handle them if received from the FS (i.e. sent by MSFS or another program). I will see... But I have also seen some bug reports on this, but I will let you know once implemented and tested.

There are two ways to use/register your new license: 1. Re-run the installer and enter your license details at the end of the installation process. Nothing else will be affected. 2. Open your existing FSUIPC7.key file in an editor (e.g. notepad++) and replace the trial key details with your purchased license details. Cheers, John

There is a new(ish) system event PAUSE_EX1 that can be used to detect 'active pause' as well as other pause states. I will look into this to see if I can improve the detection of the various pause states, One of the main problems with this is detecting the various pause states when FSUIPC is started after the sim has been put into a pause state, as I have to also consider the fact that FSUIPC can be started at any time and must accurately report the state of the sim. Hopefully this new sim state event will help with that. John

They are just different pause states, and either one or both can be active at the same time. 'Pause Set' doesn't seem to pause everything - for example you can still here the sound of the engine. I think this is still different from 'active pause' though. And note that none of these pause states stop the sim time - the only way to do this is from the devmode options menu in MSFS. So there are actually 5 distinct pause states, and multiple ones can be active at the same time: - pause set (also pause toggle) - pause on/off - active pause - escape pause - devmode pause I would generally recommend only using the 2nd method, pause on/off. I have noticed a few issues with the pause state offset 0x0264. It is now showing 0x3 when pause on is sent, when it should be 0x2. However, if you then also send a pause set with a parameter of 1 (to also turn pause set on), then send pause off, it changes to 0x1 (pause set active) which is correct, and you then need to send a pause set 0 (clear) to resume. There are also issues now with the pause control offset 0x0262. Setting pause states seems to work ok, but not clearing them. I will look into these issues next week. Cheers, John

Thanks for the update - glad you found it!

Hi Luke, I don't know - I only check offsets if/when an issue is reported. I can take a look again if you think there is an issue. This offset changed many times in the first few years but I haven't looked at it in a while. There was a recent change/update to the active pause in MSFS, which basically improved this pause state a bit (although I still wouldn't recommend using this) - see the MSFS release notes for details. As a long time user, you should know where to look to find this information - from the FSUIPC7 Offset Status document: Pause indicator: Shows 3 pause states with flags 0x1 (pause set), 0x2 (pause on/off) and 0x4 (esc pause) To detect when FSUIPC7 is connected to MSFS (you cannot detect it if its not connected!), you are probably better off using offset 0x026D (CAMERA STATE) - this will be none-zero when MSFS is running (and FSUIPC7 is connected). If you want to detect when MSFS is started and is in the main menu, you can use offset 0x026B (Plane in Parking State) which will change to 1 when MSFS is in the main menu. John

Ok, so you are using SimConnect, not the FSUIPC SDK. And you are requesting it as a 64-bit/8byte float (SIMCONNECT_DATATYPE.FLOAT64), not an integer/32-bits. All lvars are stored internally as 64-bit floats, but you can covert them to the actual data-type required in your code, but it is up to you to do this. As far as MSFS is concerned, lvars are only numeric - from the SDK documentation: IMPORTANT! "L:" vars can only hold numeric data and nothing else, eg: no strings, no binary values, no structs, etc... With FSUIPC7, you could also add the lvar to a free FSUIPC offset and read it from there (see Advanced User guide for details). Well, it is up to you how you interpret/what to do with the value, I cannot help with that. Looking at the MobiFlightt preset that reads this lvar (A32NX_APU_EGT), the description says: `Arinc429Word<Celsius>`, The APU's exhaust gas temperature,,when < -273.15 the ECB isn't supplying information, for example due to being unpowered. So it looks like they are using a specific datatype/class to handle this. Maybe better to ask the author of this preset (rofl-er) how to interpret this on the MobiFlight Discord channel.

I don't know anything about Arinc429 (and am not familiar with VB either!) , but you should be able to read an lvar and convert it to whatever data type you need. An lvar can hold any data type to a maximum of 8-bytes. What version of FSUIPC are you using, and how are you getting the lvar value? If you are reading as a integer, which I presume is 4-bytes/32-bits, can you not just convert that to a 32-bit binary data type?

Ok, great - although this does surprise me a bit, as it means that the simconnect setclientdata calls are not reentrant.... Let me know if you get any issues after further testing.

Could you try the attached version please: FSUIPC7.exe

No I don't... I am not sure it is... I also tried duplicating the sync script and ran 3 copies without issue. Access (read and write) to lvars is already protected (by a mutex) to prevent any issues with multi-thread access. I will add similar thread protection to the calls that send calc code so you can check with this to see if that makes a difference - I will post a new version for you to try later today. John

I can't see how the GSX_AUTO script can affect things, and I have had it running here together with your other 2 scripts for several hours without issue. I have also taken a look at your simconnect.log file. There are errors/exceptions from FenixBootStrapper (which has 5 connections, or 5 copies running....), PilotsDeck, FSUIPC7_AItraffic (expected occasionally), and some from the FSUIPC_WASM_IF (WAPI). However, the WAPI exceptions are not related to your issue, as they relate to the lvar names and values CDAs. Not sure what is causing those (I will investigate further when time permits), but I don't think there is an issue there. There don't seem to be any exceptions logged from a SetClientData call. Are you sure there wasn't a later log file (e.g. SimConnect4.log)? So, sorry, but I am at a loss what is causing this issue, and not sure what to advise or how to investigate further at the moment. I really need to be able to reproduce this issue to investigate further...

Sorry, are you saying that you now don't get the error when the GSX_AUTO script is not running?

Can you also try without the GSX_AUTO lua script running, to see if that makes a difference....

In an unrelated issue, you have a missing joystick: as the GUID of this device has changed: You could have corrected this, but it looks like you have already re-assigned quite a few thinks to the F device. To correct this, review all your assignments to D, and either delete or change them to F. Then remove those two D entries. If this happens again, you can recover by copying the GUID value of the new entry to the old one, and then remove the new entries,

If I can't reproduce here, I will need to see your SimConnect.log file. See the FAQ section on how to enable this: They will be very large... Also, check the max number of simconnect clients allowed in your SimConnect.xml file (MaxClients), and set to a minimum of 64 if not already.

How long? Its been running here for > 30mins without an issue so far, and the Auto script is also running, and I have assigned buttons to toggle the flags, and can't reproduce the error whatever I do. So this does seem peculiar to your set-up somehow...