John Dowson

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.

No problem - thanks for the update. John

No. FSUIPC7 includes the MobiFlight preset list (events.txt file) and all presets execute calculator code which is handled by the FSUIPC WASM module. A preset is just a name assigned to a calculator code string. You can also define your own presets in a file called myevents.txt. FSUIPC7 presets can also be parameterized (i.e. accept a parameter) which the MF ones don't. This doesn't prevent you using the MobiFlight WASM module if you want to to down that route. To use the MobiFlight WASM module with FSUIPC7, you would use event files (*.evt, included in the EventFiles folder of your FSUIPC7 installation folder) to make the events known to FSUIPC7. However, I think its simpler and more efficient to use presets these days rather than the event files, and you don't need to install the MF WASM module for this. John

Then copy it again and check the contents - should contain the following: There is a key file which also includes a trial license for WideFS in this post if you want to try WideFS as well: You could do that I guess, but you can also make the toggle switch send the control directly using FSUIPC offsets. You can send any control via offset 0x3110, and you can activate presets (if using these) by preset name using offset 0x7C50. John

When you uninstall manually and then re-install, FSUIPC will default to the install location C:/FSUIPC7 as it has no knowledge of your previous installation (as you have uninstalled it!). When the installer uninstalls, it remembers the location and will default to the previous installation location. Whenever you install, you should always check and set the installation location that you use. I have no idea what caused your issue. From what you say, the installer does contain the correct version. The installer should also detect your current installation and then uninstall this, which should remove the WASM module and manifest file, as well as everything else (but just checked and it leaves a hvar file and so also the top-level fsuipc-lvar-modules folder and also the nodules folder under this - I will correct this in the next release). Maybe next time you install, after the installer has ran the uninstaller, check what you have left under your Community folder.

Did you restart FSUIPC7? Are you sure you placed the file in the correct folder - check by using the Open Installation Folder menu option under the File drop-down menu. Also check the file is called FSUIPC7.key Why do you need to assign keystrokes first, and not just directly assign your cockpit' buttons/switches directly to the corresponding functions? John

No, sorry - the EXE.xml looks ok. A few people seem to be having this issue. Check that FSUIPC7.exe is not set to run as an administrator, and maybe check the permissions on the file and folder. If you cannot get the EXE.xml to start FSUIPC7, you can switch to the older method of starting FSUIPC7 via the MSFS.bat file (used by the MSFS icon that FSUIPC7 installs on your desktop). See the following posts: John

FSUIPC7 is aircraft agnostic - it just provides access to the events and simulator variables (A:vars, L:vars) and allows you to execute calculator code on the FS. Assign your key press to the function that performs that operation. For the FBW (and many aircraft) where many standard controls don't work, you can search for a preset that implements the function using the MobiFlight HubHop resource: https://hubhop.mobiflight.com/presets/. Looking at that, I can see OVHD ELEC BATTERY 1 TOGGLE preset which is listed for the FBW dev version of the A320. You can assign to that using the control 'Preset: OVHD ELEC BATTERY 1 TOGGLE'.