John Dowson

That is strange - many people get issues when calibrating the throttle in FSUIPC for PMDG aircraft... It is still not clear to me if you have any issues or not, but if you do, I cannot advise anything further than I did in my original post.

I am slightly confused by your post...are you assigning in MSFS or in FSUIPC? As I don't have the PMDG 737, it is difficult for me to advise on how the reversers work in that aircraft in MSFS. For the P3D PMDG 737, you can assign the throttle in FSUIPC but without calibration. For the reversers, you would normally program a throttle button (or the button detent on the throttle axis, if you have one) to send repeated throttle decrement controls (when throttle is at idle) and then send a throttle cut on button release to bring it back to idle. However, I have no idea how the reversers work in the MSFS - this has additional reverser controls that may be used instead. You could try activating logging (both for Events and Axis Controls) and reversing via the cockpit UI to see what controls/events are logged. Otherwise, check the documentation that came with the aircraft or ask about this on the PMDG forums. John

Yes - see the LuaPath ini parameter, Advanced User guide page 9.

To be honest, I have no idea how your set-up is working. FSUIPC4 (and all versions of FSUIPC prior to FSUIPC7) are dlls and run in the FS they are designed to work with. You cannot even install them if there is no FS for that version, so I have no idea how (or if) your TRC link and RCSLink software are using them. FSUIPC7 will log the events and simvar changes that it sees in the FS, regardless if where the events and simvar updates come from, and will log both when used on the server or on a client PC. The button/key events will only be logged when seen, i.e. for button/key events initiated from the PC on which it is running. Yes. Or you can open the FSUIPC7.key file and replace the trial license details with your own. John

What do you mean by this? What is 'old FSUIPC'? What version of FSUIPC are you using? It shouldn't make a difference where your assignments are - FSUIPC logging logs all sim events, not just those sent via FSUIPC. And the offsets hold the FS' simvar values and will update whatever is changing them. And if you are using TRC LInk and RCSLink software for your assignments, why did you ask me to correct your ADF swap issue in FSUIPC: ?

Please always attach your FSUIPC7.log file if you think FSUIPC7 has crashed - this usually shows that FSUIPC7 exited normally due to an MSFS CTD. If/when MSFS crashes, this can cause an exception (in the event viewer) for FSUIPC7, but this is usually due to the MSFS CTD. Check the event viewer again to see if there is an MSFS crash reported before the FSUIPC7 event, but it is the FSUIPC7.log file that would help in determining what actually happened. In all cases, MSFS CTDs should be reported to Asobo. As FSUIPC7 is an external program that only communicates with MSFS via the MSFS-provided SDK, and crash in FSUIPC7 (if it did actually crash) should not affect MSFS, and if it does, it is an issue with the SDK (which is an Asobo/MSFS issue). John

I have just checked this with a simple lua script: And when I run this and list the lvar values I see: A320_FCU_SHOW_SELECTED_HEADING = 2147483648.000000 A320_NE0_FCU_STATE = 2147483649.000000 So values > 2^31 are being sent and applied correctly. I therefore suspect that it is the aircraft model that is not accepting such values. You can also verify that the value is being sent and applied correctly by setting Debug (or maybe Trace) level logging in the FSUIPC WASM module and check the FSUIPC_WASM.log file to see what values the WASM is applying (see the Advanced User manual for details). John

It seems that occasionally FSUIPC7 is not starting everything correctly when MSFS comes out of the main menu. I am not sure why this is happening at the moment, but it seems that occasionally MSFS is not sending the correct events to indicate that it is out of the main menu. I am looking into this, but if you find that your assignments are not working, you can either restart FSUIPC& or, perhaps easier, disconnect from MSFS and then re-connect (from the MSFS menu). John

That indicates that the WASM isn't currently active. Exit FSUIPC7 and re-start it (not MSFS - keep that running). It should be like that when MSFS is in the main menu, but when an aircraft is loaded and ready to fly those grayed-out options should become active.

I've tried this here and this does work (I am just using some lvars for the A320 when not loaded for this test): A320_FCU_SHOW_SELECTED_HEADING = 2147483649.000000 A320_NE0_FCU_STATE = 2147483648.000000 So it does look like this might be an issue with the lua handling, or how the lua numbers are passed to the FSUIPC C lua library. I will look into this in further detail when I get time (most probably not until next week I'm afraid), but in the mean-time you could maybe try adding the lvar to a free user offset and then updating the lvar by writing to the offset instead. John

Yes - I tested it and it works. Looking at your log extract, the preset isn't being executed. This is what it should look like: Do you have the FSUIPC7 WASM module installed and enabled? i.e. do you have an Add-ins->WASM menu entry, and under that is the first entry 'Disable' and are all the other entries enabled? Once you have checked that, if you still have issues, please attach your full FSUIPC7.log file.

You need to copy it to your current FSUIPC7 installation folder, replacing the FSUIPC7.exe that you have installed. John

This is incorrect and should be: press trigger -> Move pov hat down -> release pov hat -> release trigger i.e. you should set the trigger button before you activate the button to which the trigger applies. Activating the trigger once a repeat assignment has been activated on the non-triggered assignment is going to cause issues - you just shouldn't do this. I don't think there is anything I can do about this, due to the way repeat assignments are implemented. It has been this way for many years and this is not something that I think is worth looking into - just use the trigger in the correct order. John

Just rebooted to check this and its all fine here - FSUIPC7 starts as expected when I first run MSFS. I've no idea why it doesn't start the first time you run MSFS. All I can suggest is that you start manually when this occurs, or go back to the old method of starting FSUIPC7 as I said in my initial post on this topic. John

No need - and no point. If FSUIPC7 is not starting, there will be no FSUIPC7.log file created (the one there will be from the previous run). And, as I said, there is nothing I can do about this - it will be an MSFS issue. John

Hi Andrew, yes - it seems that all of the WASM ini parameters are currently case sensitive. I will change this in the next release. Thanks for pointing this out. John

So the auto-start is nor working the first time MSFS is ran after a reboot...very strange... There are several reports of auto-start issues after the SU9 update (check the support forum for details) but this is the first time that it has been mentioned that this only occurs on the first run of MSFS after a reboot. I will check this here later, but if it is an issue it must be with MSFS and not FSUIPC7, as it is MSFS that is starting FSUIPC7 via the EXE.xml file. If it is an issue, it should be reported to MSFS/Asobo. You can always start FSUIPC7 manually the first time you run MSFS after a reboot. Alternatively, if this is an issue, you could start FSUIPC7 the old way, via the MSFS.bat file, rather than using the EXE.xml method. To do this, re-install but do not select to install the auto-start component. After installation, open the MSFS.bat file (located in your FSUIPC7 installation folder) and remove the comments from the line that starts FSUIPC7, and also the comments from the delay line- see this post for further details: John

This doesn't surprise me as the maximum value of an int/long int is 2^31-1. But the callback code is adding either 536870912 (left single) or 2147483648 (right single) to the value of L:ext_lights_event (although I don't fully understand that code!), so I don't think you should be setting this lvar to such values... Try looking at what that lvar actually holds (using the lvar logging menu item) and see how that changes when you set/change the landing lights in the UI. If the aircraft is using integer values outside if the int range (i.e unsigned int values) then I don't think these can be used via lua. You could also try setting the lvar value using the Add-ons->WASM-> Set Lvar... menu item - can you set such values from there?

I have checked this and it seems to be working fine here. To what control have you assigned your button? Assigning to ADF1 Radio Swap works as expected here and the active/standby frequencies are switched as expected. Check that you have assigned to the correct control, and try logging the ADF active/standby frequency offsets 0x0284 and 0x034C (as U16 in hex). This is what I see in the FSUIPC7.log file when I swap the ADF frequencies (also with event logging activated): First swap: Second swap: John

The issue was that key assignments are not written correctly to your FSUIPC7.ini file. I have corrected this in the attached version, v7.3.4c. if you could try this. Please remove any current key assignments to presets from your FSUIPC7.ini file before running this (in an editor). John FSUIPC7.exe

Yes, it seems that assignments to presets via key presses are not currently working. I am looking into it and will post and update when fixed. Sorry about this. John

Check that your FBW A320 Dev version is up to date. You can also try logging key presses to check that the preset is being used/sent. If it is, then the preset isn't working and you should report to MobiFlight (or ask about this on their Discord channel). I've finished for the day now - I can take a look to see if it works here tomorrow if you are still having issues. John

This will almost certainly not be a problem with FSUIPC7 but with your assignments (or possibly an issue with the aircraft). How have you assigned the ADF swap? Many MSFS aircraft do not use or respond to the standard SDK events/controls... Have you checked (with logging) what event(s) the aircraft is using, if any, when you swap the ADF in the cockpit UI? If not, try that. Also try seeing what lvars are available - it may be possible to swap via using lvars - list the available lvars (using the Add-ins->WASM->List Lvars menu item) and if any look relevant, see if they change when you switch the ADF. Also check the MobiFlight HubHop resource (https://hubhop.mobiflight.com/) to see if any presets are available for this. I can take a look tomorrow or later in the week if you are still having difficulties, but you should at least try looking into this first. John

No. You shouldn't change that file as any changes would be lost when you update FSUIPC7. You can use the myevents.txt file to add your own presets. Yes - there seems to be a mismatch between the preset list in the MF HubHop site and the actual presets in the events.txt file. Just took a look at the events.txt file, and the preset is there but called A32NX_OH_ELEC_BAT1_TOG, so first try Preset: A32NX_OH_ELEC_BAT1_TOG. If that doesn't work, create a myevents.txt file and add the following line: OVHD_ELEC_BATTERY_1_TOGGLE#(L:A32NX_OVHD_ELEC_BAT_1_PB_IS_AUTO, Bool) ! (>L:A32NX_OVHD_ELEC_BAT_1_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) Not sure why there is a mismatch. The events.txt file will be slightly out-of-date, but that preset is dated 11/9/2021 which is well before I updated the events.txt file included with FSUIPC7 - I update this on each release of FSUIPC7. I've just downloaded the latest events file and this seems to have been corrected, and also includes some new presets: //Fly By Wire/A320-Dev/Electrical FORCE_OVHD_ELEC_BATTERTY_1_OFF#0 (>L:A32NX_OVHD_ELEC_BAT_1_PB_IS_AUTO) 0 (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) FORCE_OVHD_ELEC_BATTERTY_1_ON#1 (>L:A32NX_OVHD_ELEC_BAT_1_PB_IS_AUTO) 1 (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) FORCE_OVHD_ELEC_BATTERTY_2_OFF#0 (>L:A32NX_OVHD_ELEC_BAT_2_PB_IS_AUTO) 0 (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed) FORCE_OVHD_ELEC_BATTERTY_2_ON#1 (>L:A32NX_OVHD_ELEC_BAT_2_PB_IS_AUTO) 1 (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed) OVHD_ELEC_BATTERY_2_TOGGLE#(L:A32NX_OVHD_ELEC_BAT_2_PB_IS_AUTO, Bool) ! (>L:A32NX_OVHD_ELEC_BAT_2_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed) OVHD_ELEC_AC_ESS_FEED_TOGGLE#(L:A32NX_OVHD_ELEC_AC_ESS_FEED_PB_IS_NORMAL, bool) ! (>L:A32NX_OVHD_ELEC_AC_ESS_FEED_PB_IS_NORMAL, bool) OVHD_ELEC_APU_GEN_TOGGLE#1 (>K:APU_GENERATOR_SWITCH_TOGGLE) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_APUGEN_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_APUGEN_Pressed) OVHD_ELEC_BATTERY_1_TOGGLE#(L:A32NX_OVHD_ELEC_BAT_1_PB_IS_AUTO, Bool) ! (>L:A32NX_OVHD_ELEC_BAT_1_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) OVHD_ELEC_COMMERCIAL_TOGGLE#(L:A32NX_OVHD_ELEC_COMMERCIAL_PB_IS_ON, bool) ! (>L:A32NX_OVHD_ELEC_COMMERCIAL_PB_IS_ON) OVHD_ELEC_EXT_PWR_TOGGLE#(A:EXTERNAL POWER AVAILABLE:1,bool) (A:EXTERNAL POWER ON:1,bool) ! and if{ 1 (>K:TOGGLE_EXTERNAL_POWER) } els{ (A:EXTERNAL POWER ON:1,bool) if{ 1 (>K:TOGGLE_EXTERNAL_POWER) } } OVHD_ELEC_GALY_AND_CAB_TOGGLE#(L:A32NX_OVHD_ELEC_GALY_AND_CAB_PB_IS_AUTO, bool) ! (>L:A32NX_OVHD_ELEC_GALY_AND_CAB_PB_IS_AUTO, bool) OVHD_ELEC_GEN1_TOGGLE#(>K:TOGGLE_ALTERNATOR1) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_GEN1_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_GEN1_Pressed) OVHD_ELEC_GEN2_TOGGLE#(>K:TOGGLE_ALTERNATOR2) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_GEN2_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_GEN2_Pressed) Overhead_Elec_Bus_Tie_Auto_Toggle#(L:A32NX_OVHD_ELEC_BUS_TIE_PB_IS_AUTO, bool) ! (>L:A32NX_OVHD_ELEC_BUS_TIE_PB_IS_AUTO) So I would use this latest events.txt file, attached below. John events.txt

Yes - try assigning the key press to Preset: OVHD ELEC BATTERY 1 TOGGLE, as I suggested.