John Dowson

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

I cannot reproduce here - both scripts seem to run just fine... Are you using any other WAPI clients at the same time? If so, do you have any WAPI log files for those? What are these programs that you are also running: ? Can you try with those disabled to see if that makes a difference please. And this change occurred when you set trace logging? If you go back to Debug or Info logging, does iiiit revert to previous behaviour? This is all very strange....

Unfortunately your logs still don't reveal much. I will need to see a SimConnect.log file, but it may be easier if I can reproduce the issue here. You say: How do you trigger these functions? By setting a flag (1-8)?

Sorry, I meant if this was a new issue in 7.3.23, or if this was working in a previous version and if so what version that was.

Could you try the attached version please. There is a minor change, but I don't think this will resolve your issue. but I have added extra logging which should help me track this down. Can you activated logging for Extras and show me the log file from this version. Thanks. John FSUIPC7.exe

License sent. John

I have moved your post to the FSUIPC7 support sub-forum. You should really try FSUIPC7 before purchasing - a trial license is available via a topic/post at the top of this forum. The SDK is only one part of FSUIPC, and that is for developers and free to use (ie. no license required). Start with the FSUPC7 User guide, which will have been installed in a FSUIPC7 folder of your Windows Documents folder. This should explain how to assign and calibrate an axis. John

👍

Is this a new issue with 7.3.24? Could you try the attached version please - I have just updated the logging to log the error number for the failed execute calc code call. Can you repeat your test with this version, set Debug level logging un the WAPI, and then show me your updated FSUIPC7.log file, as well as your FSUIPC7.ini file and your FSUIPC_WASM.log file. Maybe also a good idea to set Debug level logging in the WASM as well. John FSUIPC7.exe