John Dowson

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).

Please use the specific sub-forum for all issues/questions with FSUIPC7 and MSFS2020/MSFS2024. Previous speed issues (usually during climb) have been reported (several times) with PMDG aircraft, and this has been attributed to flaps assignment. Please see the following post: Thats for the 737 but should also apply to the 777. If that is not the issue, then I would need to see your FSUIPC7.ini and FSUIPC7.log file (with appropriate logging activated showing your issue). But please see that topic first, and at least attach your FSUIPC7.ini so that I can see your assignments. No point in posting images. John

Displaying text in (simconnect) text windows has been broken in MSFS for a long time...it did work in limited circumstances in earlier versions of MSFS but has been broken for a long time. The MSFS SDK SimConnect_Text function has basically now been removed from the MSFS SDK and it is no longer possible to use any of the text display functions (to external windows) that use this. The only way now that can be used to display text in an external window is to use the lua Wnd library. Due to this, the FSUIPC offsets for text display also no longer work (they should be marked as such in the offset status document). I have been meaning to update these offsets to use an external window as provided by the Wnd library, but just haven;t had time to look into this in detail so far. So your only option for text display in a separate window is to use the lua Wnd library at the moment (and for the foreseeable future). No, FSUIPC does not do this - if assigned to an axis, it sends the axis controls regardless of aircraft. You should be able to use axis assignments with PMDG. The issue with axes assignments in PMDG is not the assignments, but the calibration. If you assign using 'direct to FSUIPC calibration' and calibrate, this should work. But if not, you should assign using 'Send to FS as normal axis'. I think the problems are caused when assigning using 'Send to FS as normal axis' and then calibrating in FSUIPC, due to conflicting event priority levels between the PMDG aircraft and MSFS. However, I am not 100% sure on this (I don't generally use/fly PMDG aircraft, but do have some to investigate issues). I am not that familiar with the MSFS version, but perhaps this also has to do with how they are set-up in the flypad (if my memory is correct, although this may be for the FBW...). But if you have any issues, let me know and I can take a look. No problem - and thanks for your kind words. John

I have taken a quick look and offsets 0x3364 (ready-to-fly flag) and 0x3365 (in-menu/dialog flag) can't be used for this. The camera state offset 0x026D goes to 11 (waiting) then back to 2 when you restart a flight, so try that. I will look into updating the ready-to-fly offset 0x3364 to reflect the correct state, John

If you use lua auto-start, the lua is always started when the flight starts, and killed when the flight finishes. For restart, check the camera state, as advised. It will go through various values then back to 2 when the flight is ready. You should log the value of this to see what values it goes to on restart before back to 2.

Can you clarify what you mean by this? What does this mean? Do you have a reference? I'm not exactly sure what you are after, but maybe try logging the camera state offset, 0x026D. This will go through various values and then back to 2 (cockpit) (or maybe 3 - external/chase). If you log this offset, you can probably determine the value changes you need.

Yes - that is strange - maybe they are just events that are continually being sent. Many aircraft do this, and such events can be ignored using the DontLogThese ini parameter (see the documentation on using this). However, I do see that you have an axis assigned to Flaps using 'direct to FSUIPC calibration' but have not calibrated the flaps. Does this work? Usually such flaps assignment with PMDG aircraft can cause issues (especially loss of power on climb). The usual method to assign flaps for PMDG aircraft is to use the custom controls (or also preset in MSFS) to be sent on entering/leaving an axis range (i.e. using the right hand side of the axis assignment panel) - see the following topics: As for your reverser 2 issue, there is nothing I can see in the logs. One thing that can prevent the reverser activating is if the throttle is not at 0 (can be changed by setting the MaxThrottleForReverser ini parameter). So it may be worth logging the throttle values to check these are 0 - to do this, add logging for both offsets 0x088C and 0x0924 as S16. Your throttle1 and throttle2 calibrations are also different around the null zone: It is strange that the lower number is positive and not negative...although these values shouldn't really be used when calibrating throttles with no reverse zone - but maybe just set them to be the same values in the ini, just to be sure. You can also check that the out value of your throttle axes are both 0 (when no throttle is applied) in the axes joystick calibration page 3. Can you also check your assignments in MSFS are empty, just to make sure. Other than that, I will need to investigate here further as I am not familiar with the Reverser axes or how they are implemented, I won't have time today (finishing now for the weekend), but I will look into this further on Monday. John

I don't think this can have anything to do with anything in the last update, but I have attached the previous version below so that you can test with this to make sure. Just temporarily rename your current FSUIPC7.exe, download the attached to your FSUIPC7 installation folder and test with this version: FSUIPC7.exe The attached log file is of no use as there is no additional logging. Could you set logging for Events and Axes Controls and generate another log file showing your issue, and attach that together with your FSUIPC7.ini file and I will take a look. Use both Reversers 1 and 2 so that I can see any differences. Use the latest version for this! John