John Dowson

But, as I said, you have no key assignments (i.e. assignments to key presses/releases) in your ini file. Are you sure you have made some in FSUIPC? I have never heard or seen FSUIPC lose an entire key assignment section... You can also check (or send me / attach) your back-up FSUIPC7.ini file, from the backup-ini folder. This will contain your assignments as they were when you installed version 7.5.4. John

You do not have the WASM installed - from your log file: Did you try to install the WASM? If not, re-install and accept the default options. If the WASM is then still not installed/detected, please show me the InstallFSUIPC7.log file. The ProSim WASM probably handles the specific events that control the ProSim 737. You would need to assign somewhere, such as in FSUIPC7, to have these events triggered and sent to the sim/wasm. Also, please always exit FSUIPC before attaching files. The log file you attached shows that FSUIPC was still running. John

If you mean assignments to keys, then there are none of these in your ini file. Or do you mean button assignments to send key-strokes? If so, this also depends on the key presses also being assigned in MSFS. John

You did not set logging for Buttons & Keys (Log -> Buttons & Keys) as I asked for, so your log file tells me nothing. Please set this logging and try again, and also provide some information as to what is not working. You are also not using substrings for your aircraft profile names. This means that any variant you load will not match a profile that is not already in the profile, and so the assignments for that profile will not be loaded. When you add an aircraft to a profile (or crate a new profile), you should always edit the name added to the profile section to make it a substring that matches all variants. I have done this for you in the attached ini, so please download and use this one. John FSUIPC7.ini

Sorry - if its key assignments it cant be related to GUIDs. Set logging for Buttons & Keys for the lig file, and try an assignment that isnt working, i.e. "forgotten". If its an assignment to an lvar or preset, it could be the WASM has crashed....

No, FSUIPC will/should not "forget" or lose assignments - they should all be stored in your FSUIPC7.ini file. What can and does happen sometimes is that your device GUIDs can change, and then FSUIPC recogognises it as a new device and your old/original assignments wont be available. This can sometimes hapoen on windows uodates, or possibly when reconnecting a device to a different hub (although less likely in this case). Another reason assignments can seem to be missing is when using an aircraft with a different livery, and not using aircraft substring names in your profile section. In either case, show me / attach your FSUIPC7.ini and .log files and I can take a look. John

Ok, interesting. But you should be able to handle most things by using the FSUIPC profiles, as long as your lua names are distinct for each aircraft. For managing such a set-up (i.e. not having to copy things across manually), there is also a program called SimStarter NG that handles this kind of thing, but I don't know if thats available for MSFS, its mainly for P3D I think. For MSFS there is the MSFS Add-ons linker, but haven't looked at this for a few years. This was useful for having a cleaner MSFS Community folder for specific flights, but not sure what else it can handle these days but maybe worth taking a look at, out of interest if nothing else. But whatever works for you! Regards, John

This depends on which aircraft (and from which provider) you are using, which you don't say. It does not depend on your device/controller - every controller is just a collection of buttons, switches and axes as far as FSUIPC is concerned. You can also always use logging to see what is being used: set logging for Events (non-axis controls), open the logging console window, activate the cut-off buttons in the virtual cockpit (VC) and see what is logged, then assign to that.

By the way, you should really only add input events to offsets via a profile-specific InputEventOffsets section, as input events are always aircraft-specific. John

Well yes - I did say you should use this and add it to an offset way back near the beginning of this thread! Note that b:vars are also called 'input events', and are closely related to the input events provided by FSUIPC, but not exactly the same - its all rather confusing. The input events you can access via FSUIPC directly come via the simconnect input events,, available in both MSFS2020 and MSFS2024, whereas you can only access b:vars via calculator code, and only in MSFS2024. Also, you usually get several b-bars of the form _set, _inc, _dec, etc that map just to one input event you see via the simconnect interface, and not all b:vars have associated input events via the simconnect interface. Yes, that should be the case. Input events can fire multiple events, such as updating lvars, firing events, etc. You should prefer them over lvars, when available. However, this does not mean that sometimes they need to be used in conjunction with something else - this really depends on how the aircraft is implemented. But mostly they seem to be more complete and should be preferred, when available. John

Glad its now working, but do you know what the actual issue was?

Yes, please do - that is always helpful, although probably difficult to find. I am working on an new FSUIPC website (and support forum) where hopefully I can provide such information where it is easier to find/access. No problem - glad you resolved your issue. Regards, John

Ok, that can happen. Thats fine - whatever works for you. Just pointing out that for most things, the various FSUIPC logging facilities should be proficient enough, but you do have to 'connect the dots; as you say. Yes - you need to do it this way anyway if the position lvar only changes the position but not the actual function/lights.

I think this is the issue - or one of them. By setting this to true, the script is sending a value of +16384 for brakes off, and -16383 for brakes full on. Try setting that back to false. This variable is to reverse the brake axis values sent to the sim. In fact, the script is not clear on this and it seems that it wasn't tested properly with a reversed brake lever axis. I have corrected this in the attached script, so please try this and set brakeAxisReversed to true and leave brakeReversed as false. The second issue is that the initial brake lever offset will be set at 0, which is 50% brakes. I have also attempted to correct this in the attached script, which explicitly calls the brakeChange function to set an initial value of -16383 ( or +16383 if reversed) so that brakes are initially off. If you want the brakes initially full on, set the initial/default value of lastBrakeValue to 16383 instead of -16383 (regardless of reversing). Please try this and let me know how it goes, and show me / attach your log if any issues (with enableLog set to true). John

Note that you can see available lvars by listing them (Add-ons=>WASM->List Lvars) - no need to use the MSFS behaviors dialog, except as a last resort (i.e. usually to discover b-vars or h-vars). No problem about the incorrect lvar name - these things happen...! Now you have the correct name, you should check if setting that directly works to control the switch. If so, the assignments can be simplified as you don't need the compound condition on the position of your switches, and you only need to send the one one command to change the lvar two positions instead of three (e.g. switch up, pause, switch up). Anyway, you should try and understand those assignments and try to assign yourself the next time you want to make a conditional assignment. I will help if you run into problems, but you should have enough info in this thread to make a start. Regards, John

Your ini is also a bit of a mess. I have cleaned-it up a bit. Your device names/guids changed a few times, so I gave removed unwanted entries and corrected one missing one. I have also updated your profiles to use substrings, so you don't have to keep adding variants to profiles. FSUIPC7.ini

Just took a quick look at the logs. You started to test BEFORE the lvars were available (5 seconds or so too early), so the first two button presses (26 and 29) had no effect. then the next few had no effect as the switches were out-of sync with the VC. The log does show some movement of the switch (or change of value of the lvar) - three switch-down commands were sent: 13672 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) 13735 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) 15485 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) Did you not see any movement of the switch at all? Also add logging of offset A002 (using Log->Offsets). Show me /attach another file with the lvar (L:VC_POSITION_LIGHT_SW) and offset logging activated, and also wait a bit before you start testing, and I will take a look at the new logs tomorrow.

Ok, then the presets should work. Ok, thanks. I should have also asked you to log the value of the lvar L:VC_POSITION_LIGHT_SW. Maybe you can do this as well for the next logs - details on how to log lvars are in the Advanced User guide (you add another section to your FSUIPC7.ini to do this...). Got to take the dogs out now and am finishing for the day. I will take a look at your logs tomorrow. John

You can always compress/zip it. Your attachment limit will increase the more you post. Looking at that log, you are getting some differential braking via FSUIPC, e.g. Can you check that you also don't have the brakes assigned to the brake axis events anywhere else, i.e. both in FSUIPC and in MSFS. Also, generate another log but this time also set logging for Axes Controls. This script is also quite old and I can't remember it in detail. I will have to go over it again and get back to you. I am pretty busy at the moment so this may take a day or two. John

Also, where / in what folder did you install FSUIPC7?

So you populated them, and clicked Register and it validated? Can you open your FSUIPC7.key file and check that it contains the correct information (details are in the Installation and Registration Guide, under Invalid Key Problems). Can you also please attach your FSUIPC7.log file here - you will need to run FSUIPC7 to generate this again as there is none in that image you showed. Also, please attach your InstallFSUIPC7.log file.

Then it should work when you set them via FSUIPC....as I said, it worked for your dome lights, didn't it?

I don't know - I don't have this aircraft. Have you tried it? Use the Add-ons->WASM->Execute Calculator Code menu option, and try sending each of the following: 30 (>L:VC_Miscellaneous_trigger_VAL, number) 31 (>L:VC_Miscellaneous_trigger_VAL, number) to see if those move the switch. They should work, as that lvar controls the dome switch (with parameters 38 and 39). Also try the following: 10 (>L:VC_POSITION_LIGHT_SW, number) 0 (>L:VC_POSITION_LIGHT_SW, number) 20 (>L:VC_POSITION_LIGHT_SW, number) to see if those move the switch. If they work, we can simplify the assignments. If you still have issues, please activate WAPI Debug level logging (Log -> WAPI -> Debug) and logging for Buttons & Keys, and show me / attach your FSUIPC7.ini file and FSUIPC7.log file, the latter showing you using the assigned buttons. And always exit FSUIPC before attaching files please. John

Yes - sorry, I forgot to add the conditional letter 'C and the conditional comes after the press 'P' letter'. Should be 7=BA002=10 CP(+M, 29)M,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 8=BA002=10 CP(+M, 28)M,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}-

As you can see, the presets weren't recognised and changed to custom control 0. This is because I mistakenly used a colon for a divide between the preset name and the calculator code instead of a hash symbol - sorry about that... I don't have a hash symbol on my keyboard and I forget sometimes!. The preset should be: //iFly/737-Max8/Lights Nav_Strobe_Switch_Up#30 (>L:VC_Miscellaneous_trigger_VAL,number) Nav_Strobe_Switch_Down#31 (>L:VC_Miscellaneous_trigger_VAL,number) Nav_Strobe_Switch_Up_Two#30 (>L:VC_Miscellaneous_trigger_VAL,number) 30 (>L:VC_Miscellaneous_trigger_VAL,number) Nav_Strobe_Switch_Down_Two#31 (>L:VC_Miscellaneous_trigger_VAL,number) 31 (>L:VC_Miscellaneous_trigger_VAL,number) So change those. You also didn't change the conditional button to you M device. So, change to: [Buttons.iFly B737 MAX8] 0=BA000=0 PH,5,CPiFly737MAX8_Dome_Light_Up,0 -{Preset Control}- 1=BA000=1 PH,5,CPiFly737MAX8_Dome_Light_Up,0 -{Preset Control}- 2=BA000=2 PH,5,CPiFly737MAX8_Dome_Light_Down,0 -{Preset Control}- 3=BA000=2 PH,5,C1152,50 -{pause (ms)}- 4=BA000=2 PH,5,CPiFly737MAX8_Dome_Light_Down,0 -{Preset Control}- 5=BA002=20 PM,26,CPNav_Strobe_Switch_Up,0 -{Preset Control} 6=BA002=0 PM,26,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 7=BA002=10 (+M, 29)PM,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 8=BA002=10 (+M, 28)PM,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}- 9=BA002=20 PM,28,CPNav_Strobe_Switch_Up,0 -{Preset Control} 10=BA002=20 PM,28,C1152,50 -{pause (ms)}- 11=BA002=20 PM,28,CPNav_Strobe_Switch_Up,0 -{Preset Control} 12=BA002=0 PM,29,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 13=BA002=0 PM,29,C1152,50 -{pause (ms)}- 14=BA002=0 PM,29,CPNav_Strobe_Switch_Down,0 -{Preset Control}- John