John Dowson

You do this by using 'compound conditions'. See the Advanced User guide, page 22. John

Why don't you just keep the lua running until you go back to the main menu? Do you really need to stop/exit this and then restart? As I said, you can also use offset 0x026D to determine the camera state, with values: If the lua has terminated, it needs to be restarted. You can also just start/restart it on a button press (or from another lua) and if its currently running it will be killed. How is this lua started? Maybe you can also attach this lua script so I can take a look.

Maybe - could be due to the initial button state scan... Then I think this is because of the change I made to allow repeated LuaValue calls with the same parameter - but I'm not sure how this change could cause this error! I have disabled Button actions before everything is initialized in the attached version. John FSUIPC7.exe

This looks to be because you are pressing a button that starts a lua thread far too early - well before the aircraft is loaded and before FSUIPC is fully initialized. This looks to be confusing SimConnect and interfering with the initialization. You should really not be doing anything until AFTER you have pressed the Ready-to-Fly button. I also don't think this is related to any of the recent changes. FSUIPC should really ignore such early button presses. Not sure why it is actioning those button presses when they should be ignored. I will take a look to see if I can prevent this. But you should wait until the aircraft is fully loaded and after you have pressed the ready-to-fly button before doing anything, and really it is better to wait until all lvars have loaded, which will be several seconds after you the cockpit view is loaded. John

The camera state is not just the views, it is what is displayed in the MSFS main window, so can be Menu, World Map, Hanger, Waiting, etc As I said, 32 is undocumented (internal only) so just wondered why it hit that state when you were (probably) in a cockpit view (state 2). Its not important - just wondered if you had noticed anything in MSFS, apart from FSUIPC becoming unresponsive (as it was killing the luas).

Just wondered what you saw when the camera state when to 32. Anyway, I have removed this now in that last exe. There is another camera state of 36 that will also cause luas to be killed which might also need removing. As I said, I will do some testing later today - I haven't looked at this since the latest SU update and these things tend to change on each release... John

Check you are looking in the correct place - use the File->Open Installation Folder in FSUIPC. Also check that you have not set windows Explorer to 'Hide extensions of known file types'. If you don't know what this means, see the Addendum in the Installation and Registration guide (last page). John

The aircraft name logged was "Dirty 30 Short Configuration" which seems very strange... What actually happened in MSFS at this time? Your log indicates that FSUIPC killed the lua scripts as the camera state changed to 32 (which is an undocumented/internal camera state). In MSFS2020, the 'plane in parking state' variab1e is used to determine when a flight is ended and luas need to be killed (as well as performing other tasks needed when an flight is ended). But this is not reliable in MSFS2024, and so an additional check on the camera state was added specifically for MSFS2024, and when certain camera states are received, FSUIPC thinks the flight is ended and will stop the luas. The camera state values were determined by trial and error, and 32 was one of these (even though the exact meaning of this state is unknown). I will do some more tests on this, but I will remove 32 from the list that determine a flight has ended. I have done this in the attached version. John FSUIPC7.exe

Stick woth writing to the offset and using event.offset.Thats the standard way to use axes values in a lua script.

The only anomaly in that log is when trying to set/execute an input event that doesn't exist:

Thee is no point auto-starting the script if its not waiting for an event - it will just run and exit, and maybe adjust the trim when not needed. But please try the attached version. As well as the logging issue (hopefully) being fixed, this should allow repeated LuaValue calls using the same value. John FSUIPC7.exe

Yes, I'd forgotten about that. This is on my list to investigate as it should really trigger when you send the same value multiple times. I will see if I can also fix that as well. John

Yes, I should have mentioned that. Basically, if one program needs admin privileges, then for auto-start (either via FSUIPC or MSFS) then everything needs to be ran with elevated privileges. Previously this was possible, but windows OS is getting stricter and stricter on each release, for obvious reasons I think... I don't think there is anything I can do about this, but will look into it further when time permits. I think that for now you will just have to manually start anything that requires admin privileges. You could also ask/enquire on the support forums for any program that does this as to why this is necessary in the first place... If you find any solution, please update this thread! Regards, John

I would like to know if the lua com library can see (and therefore be used to control) your device. I think that would be the easiest solution. If not, rather than bespoke programming, you could look into MobiFlight or SIOC (from OpenCockpits). Many home cockpit builders use this in conjunction with FSUIPC. But I can't help with these products as I have never used them - I do however support FSUIPC users who use these with FSUIPC. Also, have you asked on the support for your device? It is them that should provide the software/drivers and support to communicate to the FS, especially if it is not recognised by windows as a standard "game controller", i.e. a joystick-type HID device. John

740 is a windows error number that means elevated privileges are required. The only way you can get around this is to run FSUIPC with elevated privileges,

Maybe also check the Windows Event viewer to see if thee is anything there related to this.

If it has the admin icon, then I think they must need admin privileges or they request them at start-up. Does your log show an error (with an error code) when it tries to start this? If so, the error code should indicate the reason.

There is certainly something strange with that build, as indicated by the strange characters in the lua log messages, which indicates a corruption somewhere when multiple threads are writing to the log. I will check this and provide an updated version, maybe later but probably tomorrow or Monday. John

You use SimConnect, or you can use the FSUIPC SDK for this. If your program is getting events for button presses, you can then sent an event on to P3D using SimConnect, or write to an FSUIPC offset to trigger an evemt. As I said, FSUIPC only recognises joystick type HID devices. for other devices, you can maybe use the Lua com library. Again, as I said, first try using the HidDemo.lua program. You need to edit this to provide your device PID and VID. take a look at that and try that. This will convert any buttons on your devices to virtual buttons/flags that you can then assign in FSUIPC. And it writes axis values to offsets which you can then also use. This lua script is provided as a demo, but is useful for testing if you can control your device via this. If so, then take a look at the lua com library API in the FSUIPC Lua Library document. In FSUIPC. you can also try logging your HID devices to see if this is seen - from the Lua com library documentation: John

Looks like the SimConnect connection hung, almost certainly due to MSFS hanging. I don't thing this is anything to do with FSUIPC7 or the the FSUIPC7 CTD. If this continues, we can also try SimConnect logging, but I would put this down to MSFS for now. If it was an FSUIPC issue, it should not affect MSFS - but MSFS issues will certainly affect FSUIPC. I don't see any error messages relating to the input event 'AS530_GPS_Outer' - did you correct this? Or was it that this was just not used? Could you switch to using the attached exe please. This contains a few minor logging updates/improvements. John FSUIPC7.exe

Yes, I think that would also be useful. John

Well, I did say that this was needed! Whatever you are assigning (axes, buttons or keys), you need to select/check one of the available options when not assigning to the default FS controls. John

Is FSUIPC actually running? First, check that. If it is running, check your FSUIPC7.log file and read the following post: If you are still having difficulties after that, please show me / attach your FSUIPC7.log file. John

@kaha Could you use the attached exe instead please. This is exactly the same as the previous one except that it is a debug-enabled build. It would be extremely useful if you could use this and also enable crash dump logs. To do this, see the following article: https://helgeklein.com/blog/creating-an-application-crash-dump/ If you are not familiar or happy editing the registry to do this, I can provide you with a .reg file that will add this for you. John FSUIPC7.exe

Glad you have now resolved this. I have updated the title. Regards, John