John Dowson

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

Ok, please do. It would be good to know what is actually causing this crash! When I get time, I will see if I can do anything with the crash event, but I find these difficult to use in 64bit apps...I will need to look into this further. John

There is also: L:A_MIP_LIGHTING_FLOOD_MAIN - for main flood lights Thats the only other flood light lvar I can see in the MF presets, so try: (and remove the '-1 *' if reversing not needed). John

The pedestal flood lighting knob is controlled by the lvar L:A_MIP_LIGHTING_FLOOD_PEDESTAL with values between 0 (off) and 1 (full). The X-55 rotary knobs control axes R and V, as you say, which have a range of -16384 - +16383. The easiest way to use an axes to control an lvar is to define a preset. So, add the following to your myevents.txt file (create this file if you don't already have one): Then assign your X-55 rotary to that preset by checking Send Preset to FS and selecting that preset from the dropdown menu. I think the X-55 rotaries may also need reversing -if so, you can do this by adjusting the preset by multiplying the input parameter by -1, i.e. You can control the panel lights in the same way, but I am not sure what the lvar for this is (I don't have this aircraft). Try listing the lvars (Add-ons->WASM->List Lvars) to see if anything looks appropriate. It could be one of the following: L:A_DISPLAY_BRIGHTNESS_FO (Display Brightness R PFD Knob) L:A_DISPLAY_BRIGHTNESS_CI (Display Brightness L ND Knob) L:A_DISPLAY_BRIGHTNESS_CO (Display Brightness L PFD Knob) L:A_FCU_LIGHTING (FCU INTEG BRIGHTNESS KNOB) L:A_DISPLAY_BRIGHTNESS_FI (Display Brightness R ND Knob) ...or another lvar entirely! If you can find the lvar, just define another preset similar to the one above but using the panel knob lvar, and then assign to that. John

Yes, interesting - I think continually killing and restarting lua threads can eventually cause issues (due to stack overflow issues). It makes me wonder if this is actually caused by any changes in 7.5.5 - maybe they just weren't noticed earlier, or execution is slightly slower for some reason causing a stack issue... Was this with the latest exe I posted (7.5.5d), or the original 7.5.5a version? If the latest version, maybe retest with the older version and see if that crashes? Ok, let me know how it goes.

As I posted after this, maybe keep this for the time being just while you test the new exe... You could also maybe test if this is the cause by repeatedly trying to trim to provoke a crash... John

By the way, when the crash occurs are you repeatedly trying to adjust the trim? With the current script, if a trim button is pressed when the current script is running, it will be killed and a new script started. If you press repeatedly too fast, this is what could be happening (and why button press logging could help identify the issue). You can also use/adjust the LuaRerunDelay ini parameter to make sure the script is completed before being re-invoked, so you can also maybe try increasing this slightly, e.g. try 75 rather than 66. This is not needed if you switch to event.param and LuaValue. But for now, maybe keep it as it is while you try the new exe I posted. John

Would be better and more efficient to also have that script auto-ran and modified to use event.param. Your assignments would need to be modified to use LuaValue instead of just Lua. As you have lots of assignments to this. would be easier to just do this by editing the ini - just change "CL16:R" to "CL16:V". John