John Dowson

@Mugz Please try the attached version, 7.2.1b: FSUIPC7.exe

I have found the issue. The problem is that before writing the received value to the gear position offsets, FSUIPC is checking offset 060C, the IS GEAR RETRACTABLE offset. This is 0 (i.e. still unpopulated) when the gear position is received, so FSUIPC is setting the gear position offsets to 16383. I will fix this and post you a new version to check either later today or more likely tomorrow morning. I have also found an issue with luas not starting when you start FSUIPC7 and MSFS is already running but in a paused state. This will also be corrected.

No, those offsets are only populated from simvars received via SimConnect. I can reproduce this issue now but do not understand it. I will look into it and get back to you. It also looks like FSUIPC7 isn't auto-starting luas when FSUIPC7 is started and MSFS is running but in a paused state. I will also look into this.

Use the Log -> Offsets menu option, giving the offset addresses and the code U32.

Yes, I know - I am looking into it... One thing you could/should do is delete the contents of the [General] section in your FSUIPC7.ini file and let that get rebuilt, as some of the values need updating. Once you've done this (and ran FSUIPC7 at least once), change back the following parameter: I will look into the offset value issue, when I get a chance...

@Mugz Before I add those new simvars, could you check offset 0C4C (Nav1 GlideSlope Flag), which should be TRUE if the GS is active, and false otherwise. Maybe also check the value in 0C4D.

But the log you posted shows that the offsets you are logging held 0 So, is this the correct value? If so, there is no issue with 'read wrong offset value if load in mid-flight', but the crash is an issue. Could you maybe try disabling the WASM module and test again, to see if that is causing the crash. I will also test here to see if I can reproduce. Also, please show me/attach your FSUIPC7.ini file.

The log file is in your FSUIPC7 installation folder. If you do not know where that is, you can use the File -> Open Installation Folder... menu option. If you cannot see the log file, you have windows explorer set to hide known extensions. If this is the case, please see the Addendum in the Installing and Registering FSUIPC7.pdf.

Can we please look at one issue at a time. It is starting to get very confusing as to what your actual issue is... So, lets use this topic for your issue with the the wrong values being reported. So, disable your other luas for now, and lets concentrate on this one issue. And, for this issue, please show me your full log file, where you start FSUIPC7, your script starts, and then the offsets start to be logged. Let it run for a minute or two, then exit FSUIPC7 and show me the generated log file. ...and I don't want Lua Plugin logging activated for this issue. That was for your other issue (i.e. the crash issue) - please disable while investigating this issue .

That log was from your crash - I have asked you to activate logging for Lua Plugins and repeat your test and show me an update log for that issue. The values being logged is a separate issue (and the one you raised this topic for). I see no 'Gear L N R state:...' log lines in the log you previously posted. You are logging the gear state every second - I am interested in seeing the other log statements, to see if these values change once data is received from MSFS. Its easier for me if you can always attach your full log file, rather than pasting extracts (or even the full log).

The full log would be more useful.... But the log extract you showed shows the log message was produced 21 seconds after FSUIPC7 started. Do you not see these values change as the data is received from the FS? Of not, please show me you full log, not an extract. You are posting so many messages/problems its difficult for me to keep track, and I can't investigate as I'm spending all my time responding to you! Well, that shouldn't happen either. But lets look into your other issues first...

Yes, but your FSUIPC7.log file would also have been useful. The events you posted show that it was MSFS that crashed. When this occurs, it generates a fault/exception in FSUIPC7, but FSUIPC7 should just close down nuormally as MSFS is no longer available. Your FSUIPC7.log file would confirm this. So it looks like MSFS is crashing, nd FSUIPC7 is exiting gracefully as MSFS is no longer available. You should report the CTD to Asobo, including the information from the Event viewer.

I could be an issue with your lua scripts. Do you get the crashes if not running your lua scripts? If not, could you activate logging for Lua Plugins and try again (i.e. make it crash), and show me the new crash log.

Sorry, which error? Do you mean that all event.terminate functions are called correctly if/when you exit MSFS/FSUIPC7, but not when going back to the main menu?

If FSUIPC crashes, you should save the log and show it to me. The log is also renamed FSUIPC7_prev.log when FSUIPC7 is restarted, so you will still have your previous log rvrn if you restart FSUiPC7. I cannot help you if you do not show me your logs... The windows event viewer information you posted shows a fault, not a crash. You also seem to have many such errors in your windows event viewer - are they all from FSUIPC7? How many are produced when FSUIPC7 crashes/disappears? Can you show me all such events produced (from anything, not just FSUIPC7), in order, when this occurs.

I don't understand this. Do you mean it crashed? If FSUIPC7 is crashing or not exiring cleanly, I need to see your lkohgs + any windows event information. There is no point in reporting things otherwise. So your lua scripts were not started? Do you have the logs for this? Ok - as I said, I will look into this.

If FSUIPC is crashing, please show me your FSUIPC7.log (from when it crashed), together with any event information from the Windows Event viewer. Could you be reading the values before they have been received/initialised? As I said, please show me your script and a log file showing your issue.

So MSFS crashed? If you restart FSUIPC7 and the sim has crashed, there will be no simvar values available. But is the sim running (you say it crashed)? Also, when/how are you reading this? i,e, how do you know 'in simvars i have '0' value'? Could it be that yoiu are reading the offset before the initial offset data is has been received? Please explain your issue more clearly, and show me the script and and FSUIPC7.log that shows your problem.

FSUIPC7.2.0 Ok - I've moved this topic to the FSUIPC7 sub-forum. Ok, I'll add the ARM and ACTIVE simvars - AUTOPILOT GLIDESLOPE HOLD is already available in offset 0x07FC, and post a new version for you to test, either later today or tomorrow.

First, you posted in the User Contributions sub-forum, where it states NOT for support requests. I have moved your post for you, but please take care to post in the correct forum for future requests- either here or in the FSUIPC7 sub-forum for FSUIPC7/MSFS support requests, This is not currently held in any offset. I can add this, but only for FSUIPC6 or FSUIPC7. Which version of FSUIPC are you using? Are there any other simvars that I should look into adding at the same time (e.g. AUTOPILOT GLIDESLOPE ARM, AUTOPILOT APPROACH CAPTURED, AUTOPILOT APPROACH ARM or AUTOPILOT APPROACH ACTIVE)?

Yes, it looks like only one event.terminate function is currently called, for the first lua script that is auto-started. I will look into it. However, it is probably better to merge your scripts and just have one event.terminate call anyway. i.e. put all your com handling in a single script, make that the first lua that is auto-started and have your event.terminate call in that script. You could try the following version. This should call the event.terminate functions for all scripts (but please report back!), but it will only add the TimeForLuaClosing delay to the first event.terminate call. I will look into this further and report back. FSUIPC7.exe

To use the 128 button functionality, you need the following line in the [General] section of your FSUIPC8.ini file: EnableExtraButtons=Yes However, this should be added by default - you only need to change this if you don't want the additional buttons > 32 to be recognixed. Are you saying that assigning to buttons > 32 doesn't work (i.e. the control isn't being sent), or that the control is being sent but has no affect? If you are not sure, activate logging for Buttons & Keys as well as Events, and you should be able to see the button presses and associated controls being sent in the log file (you can view in real-time using the 'Open Console' window). It is also known that many if the standard controls for the G1000 are not working. You can look into using lvars/hvars rather than standard control/events, or try with the MobiFlight WASM module and the MF events. You may also be better of installing the Working Title G1000 mod and trying with that. There is plenty of info on this on the Asobo (and other) forums.

This does not ensure that FSUIPC is the cause of the problem. FSUIPC7 is a standalone executable - if it crashes, will not affect MSFS. Did you check the windows event viewer to see if any crash or fault events were logged? If not, please check. Also, check your FSUIPC7.log file - you will most likely find that FUIPC7 exited normally as MSFS crashed - FSUIPC7 will always exit when MSFS crashes if it was auto-started by MSFS. If you find an MSFS crash event in your windows event log, you should report the crash to Asobo and include the crash report.

What scripting language (FSUIPC SDK?) are you using? And why are you opening and closing in the loop - probably better to open the connection, loop to send you gear retract/open commands, then close when done. But I'm nor sure what you are trying to do in your script. Maybe it would be helpful if you let us know what you are trying to achieve and how...

Como has asignado el boton? Tenga en cuenta que los controles de la camara no funcionan en MSFS (via SimConnect). Para controlar la camara, primero asigne una tecla (o teclas) a la función de la cámara en las asignaciones del teclado en MSFS, y luego asigne su botón a esa tecla asignada.