John Dowson

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.

This one: offsetStatus-v0.21.ods Try reading the manuals. For general lua information, use google. To find out how lua plugins work with FSUIPC, read the FSUIPC Lua Plug-Ins.pdf document. This also contains an overview of the provided examples. Then, for specific on the FSUIPC lua library, take a look at the FSUIPC Lua Library.pdf document. Also check-out the User Contributions and FAQ sub-forums on this support site.

As the message you quoted says, the spreadsheet comes in the zip file that you downloaded. The example lua programs can be found in your FSUIPC7 Documents folder, bundled together in a zip file called Example LUA plugins.zip. Of course all lua scripts are exited when you exit the Sim. FSUIPC7 also exits when the sim exits, if it is started by MSFS, and all programs started by FSUIPC7 will also exit. Why would you want to run anything when MSFS is exiting? Once the sim is exiting, there is nothing that can be done except shut-down gracefully.

It will - I will post a new one next week.

Yes, v7.2.0 is no longer in beta - it is now the latest and only supported version.

First, the format is incorrect - The offset cannot be both a signed word (SW) and an unsigned byte (UB). PLEASE see the documentation in the Advanced User guide for the format. I am not going to explain this yet again.... Second, you have added the lvar in general section (i.e. not profile specific) so it will try and get that lvar for every aircraft. It certainly won't exist for every aircraft, so you will get an error if the lvar cannot be found. Try listing the available lvars for your loaded aircraft using the Add-ons->WASM->List Lvars menu option.

For lvars, you can use the new lvars-to-offsets facility, available by editing the FSUIPC7.ini. See the Advanced User Guide for details and an example.

Yes, many. See the offset document spreadsheet - this gives the simvar names (where relevant) for the offset address. For reading/writing to these offsets via lua. check out the lua examples provided.

Spaces are optional in xml files, although help readability. The Logitech MSFS plugin has the same issue. There is an example of an EXE.xml for this in this support request: You just need multiple <Launch.Addon>...</Launch.Addon> sections, one for each application that you wish to launch. And make sure they are both within a <SimBase.Document> section.

I think it does, but I'm not sure if thats in the stable version yet. This video explains how to set up the throttles using the FlyPad/EFB, atarting at th1 10L20 maek:

You can read simulator variables that are held in offsets, using the lua ipc.readXXX functions. If the simvar is not yet held in an offset, you can request it to be added. John