John Dowson

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

Here's the first version to try: FSUIPC7.exe

Could you please set logging for Buttons & Keys, and show me the log the next time you get a crash. Also please attach your Elevator_Trim.lua script - this is not auto-ran but is just ran on a button press. I wonder why this was still running and had to be killed... As this only started with 7.5.5, I may have to roll back each non-functional change one-by-one to see which, if any, provoke this crash. Looking at the changes, there is nothing obvious but they are quite technical and I may have removed something that I thought was unneded/used but actually is... These changes were related to device handling though, and ifthere were issues I would have thought they would be more common.... I will look into providing you with some updated versions to test. John

Note that if the data held in offset 0x560D is larger than 1 byte, i.e. a word (2-bytes) or a double-word (4 bytes), you should change the size in the offsetmask function (to "UW" or "UD") and use the appropriate togglebits function (ipc.togglebitsUW or ipc.togglebitsUD).

FSUIPC will only detect joystick type HID devices. Could you show me / attach your FSUIPC6.log and FSUIPC6.ini files, and the output from the HidScanner program (should be in your FSUIPC6 Utils folder). The FSUIPC SDK only provides functions for reading/writing to FSUIPC offsets - it has nothing for devices. You should be able to use the lua com library to detect (and control/assign) your device. Start with using the HidDemo.lua and adapt that to see if it detects your device. The script should be available in the lua example scripts package in your FSUIPC6 Documents folder.

As this is a separate issue, you should really create a new topic... Create another lua script, call it MIPSwitch.lua and add the following: funtion MIPSwitchMonitor(offset, value) -- bit 5 has changed: change bit 0 ipc.togglebitsUB(0x560D, 1) end event.offsetmask(0x560D, 32,"UB", "MIPSwitchMonitor") -- bit 5 mask is 2^5 = 32 That script will change/toggle bit 0 when bit 5 is changed. However, it won't keep them in sync, so if bit 0 is changed on its own, then they will toggle out-of-sync. You can update the script if you want them always synced. The script must be running - the best way to do this is to have it auto-started, by adding the following to your FSUIPC4.ini file )still don't know what version of FSUIPC you are using, but presume its 4!): [Auto] 1=Lua MIPSwitch John

Yes, but could you either copy and paste the exception details, or export it and attach the xml file. Its difficult for me to see the details in a screenshot, and I can't cut and paste the details I need (such as for translation!). No, that won't be related - that indicates that you are trying to send an input event that doesn't exist. That is strange then and I wonder what is causing them to terminate.. I don't think the crash could cause the termination - I wouldn't expect the lua termination threads to be called if FSUIPC had crashed. Yes, that is what those messages are showing. Ok. I did say 'Note that this version contains some technical/non-functional updates that have not been fully tested yet, so if you get any other issues please let me know'! Were you running the same lua scripts in 7.5.4 without issues then, or have you changed anything? I will review the changes in 7.5.5a - but please can you show the the crash event details, either by pasting them or attaching the exported file. Thanks, John

Also, why are you auto-starting so many lua scripts with each aircraft? If they are aircraft specific (which many look to be), you should use profile-specific [Auto.xxx] sections (where xxx is the profile name).

Can you please also show me (or attach) the windows crash event (from the Event Viewer). Did you get any crashes with 7.5.4 (or earlier versions), or is this only with 7.5.5a? From the last lines in the log, it looks like FSUIPC was trying to close your lua threads: Why was this? What did you do to initiate the close of the lua threads/scripts? Why is there over a minute between the two 'Waiting...' log messages? What threads/scripts were being terminated?

No - they are standard FSUIPC offsets (maybe also documented in PM). PM specific offsets are in the range 04E0-0573 and also maybe in 5200-5FFF. By default, lua scripts go in your FSUIPC installation folder. Just create a file called ipcready.lua in your FSUIPC installation folder and add those ipc calls I gave you. But first please check that they are not already correct by logging the values of those offsets. John

Profile names can be anything - they are just used to connect to the files or the various sections in the ini - they don't have to be related to the aircraft name at all (e.g. you can use 'Jet' or 'MyProfile'). What is important, and is used to match the aircraft to the profile, are the names of the aircraft under the [Profile.xxx] sections. When matching on aircraft names (the default, when UseAirLocForProfiles is No or not set), then the aircraft name added to the profile (and used for matching when loaded) is the aircraft Title (simvar), which in both MSF2020 and MSFS2024 is defined as 'Title from the aircraft.cfg file'. In MSFS2020, for the PMDG 777 its this: However, in MSFS2024, its commented out for some reason: So the title seems to be coming from the icao_model entry instead. But in both cases. FSUIPC takes this from the value of the Title simvar provided by MSFS - it does not read the aircraft.cfg file directly. It uses what MSFS provides. When using UseAirLocForProfile=Yes, the folder name containing the aircraft.cfg file is used. In MSFS2020, this is: Community\pmdg-aircraft-77w\SimObjects\Airplanes\PMDG 777-300ER whereas in MSFS2024 it is: Community\pmdg-aircraft-77w\SimObjects\Airplanes\PMDG 777-300ER\common\config which is where that config entry is coming from. And this location is different for different add-ons in MSFS2024. For example, for the JustFlight Piper Arrow, its: Community\justflight-aircraft-pa28-arrow-bundle\SimObjects\Airplanes\JF_PA28_Arrow i.e. the same location as used in MSFS2020. So even though the PMDG aircraft isn't streamed, it is probably not a good idea to use the aircraft.cfg file folder name for matching in MSFS2024- and certainly not when using streamed aircraft. John

Which version of FSUIPC and which FS are you using? I am not sure that they are the correct offsets to use. Try logging the values first, using FSUIPC's offset logging facilities. Also try logging the oil pressure offsets, 08BA and 0952. You may find they already hold the correct values. You would want to do this when the aircraft is loaded, not when the sim is started. To do this, you can use a script called ipcReady.lua, which is ran automatically when an aircraft is loaded and ready-to-fly. To write to offsets 08D0 / 0968, they are 4 bytes so you would use the function ipc.writeUD (or maybe ipc.writeSD), e,g, ipc.writeUD(0x08D0, 16384) ipc.writeUD(0x0968, 16384) As offsets 08BA and 0952 are 2 bytes, you would use ipc.writeUW: ipc.writeUW(0x08BA, 16384) ipc.writeUW(0x0952, 16384) You can try this But as you are using Project Magenta, it may be using its own offsets anyway. You should ask about this on PM support. John

Why do you think this? If you open the axes assignment dialog, do you see the profile name in the window title? If you think a profile isn't being loaded, I need to see the log file with logging for Buttons & Keys activated and a button press for a profile-specific assignment, as well as the FSUIPC7.ini and profile-specific ini file. Yes, I can see this is an issue. This is because you are using UseAirLocForProfiles=Yes and as aircraft in MSFS2024 are streamed, the folder containing the aircraft.cfg file is not actually available. I will look into this to see if anything can be done (but I doubt this for streamed aircraft), but for now you should not use this option if using MSFS2024. So please either remove this or set it to No. I will clarify this in the documentation. After changing/removing that setting, you will also need to update the profile aircraft names (or add each aircraft back into the profile), e.g for the PMDG772LR profile use: [Profile.PMDG772LR] 1=777-200LR However, I would have expected the profile to still have been loaded, as your log indicates that the 'config' folder is being used, and that should match. However, I suspect that the same folder may be used for other aircraft, so that the same profile is being used for all/most aircraft. Anyway, try removing that option, update your profile aircraft names and let me know if you still have issues. Note that in the next release, the profile that is being used will be logged in the FSUIPC7 main window. John

Btw, which of Toag's helicopters are you using?

Its not that difficult and I can show you how to use these things, if they are available. I don't have this helicopter so you just need to follow my instructions to let me know if there are any input events available (I already showed you what to do for this) or any appropriate lvars (just list them using Add-ons->WASM->List Lvars and then show me / attach your FSUIPC7.log file). Up to you, but assignments to lvars/hvars/input events are getting more and more common with add-ons and it is worth getting to know how to use these type of controls. Worth at least taking a look - there may not be anything available anyway... Yes - and certainly in my hands! I've not got far with trying to fly helicopters, but then I haven't spent much time in them either. Cheers, John

@bcars I have looked into this in more detail now I am back, and basically find the same as you. However, if you disconnect from MSFS (MSFS->Disconnect), then the RunReady/CloseReady applications are stopped correctly. So this indicates that it was a timing issue, and FSUIPC was basically exiting before it issued the WideServer close-down request. I have corrected this in the attached version, where WideClient should close down together with all Close/CloseReady apps both when exiting FSUIPC and when exiting MSFS, so please try this version. I did notice one other strange issue though: the CloseAppsHotKey works to close the CLose/CloseReady apps, but the CloseReady/RunReady ones are started again a few seconds later. Not sure if this is intended.... John FSUIPC7.exe

You could also maybe try AXIS_COLLECTIVE_SET (the old helicopter throttle axis). Also try looking at the input events to see if there is anything there that controls the throttle. If there are any input events available (the number of input events available is logged in FSUIPC's main window), first list them (Log->List Input Events), If there is anything that looks applicable, log input event changes (Log->Input Events) and turn the throttle in the VC and see what is logged, and get the max/min values for the input event. If anything exists, I can show you how to use this to assign to your axis. You can also check for lvars to see if there is anything there that looks throttle related. John

There are multiple (helicopter) throttle axes - have you tried HELICOPTER_THROTTLE1_SET? If there is only 1 throttle, also try HELICOPTER_THROTTLE_SET or maybe AXIS_HELICOPTER_THROTTLE_SET These are the (newish) helicopter axes available: 67526 HELICOPTER_THROTTLE_INC 67527 HELICOPTER_THROTTLE_DEC 67528 AXIS_HELICOPTER_THROTTLE_SET 67529 HELICOPTER_THROTTLE_SET 67530 HELICOPTER_THROTTLE_CUT 67531 HELICOPTER_THROTTLE_FULL 67532 HELICOPTER_THROTTLE1_INC 67533 HELICOPTER_THROTTLE1_DEC 67534 AXIS_HELICOPTER_THROTTLE1_SET 67535 HELICOPTER_THROTTLE1_SET 67536 HELICOPTER_THROTTLE1_CUT 67537 HELICOPTER_THROTTLE1_FULL 67538 HELICOPTER_THROTTLE2_INC 67539 HELICOPTER_THROTTLE2_DEC 67540 AXIS_HELICOPTER_THROTTLE2_SET 67541 HELICOPTER_THROTTLE2_SET 67542 HELICOPTER_THROTTLE2_CUT 67543 HELICOPTER_THROTTLE2_FULL 67544 AXIS_CYCLIC_LATERAL_SET 67545 AXIS_CYCLIC_LONGITUDINAL_SET 67546 CYCLIC_LATERAL_LEFT 67547 CYCLIC_LATERAL_RIGHT 67548 CYCLIC_LONGITUDINAL_DOWN 67549 CYCLIC_LONGITUDINAL_UP

No. As I have said, you need to use the camera state to see if there has been a restart. MSFS does not provide any events/information when a flight is restarted, so it was never possible to detect this in FSUIPC. However, since the addition of the camera state variable (in late 2022) you could use this, as I have said. This is basically correct although a little outdated. To be more precise, the luas are started in order on initial load of an aircraft and once the available lvars have been received and are available, and are stopped/killed whenever you go back to the main menu (i.e. end the flight).