John Dowson

I suspect that the aircraft is not using the AUTO BRAKE SWITCH CB simvar, as this always seems to be 1 (off). Could you check to see if there is an lvar available that holds the current autobrake setting? To do this, you need to assign a button or key press to the List Local Panel Vars control, and press the assigned button/switch once the aircraft is loaded. This will then list all lvars and their values to the FSUIPC6.log file. John Later: I see the autobrake selector switch position is available via the iFly SDK:: BYTE Autobrake_Selector_Status;//0:selector RTO 1:selector OFF 2:selector 1 3:selector 2 4:selector 3 5:selector MAX AUTO However, there is no access to this via FSUIPC at the moment. I do intend to investigate adding the iFly SDK data to FSUIPC offsets at some point, when time permits, but currently don't know when I will have time to look into this. So, for now, you need to tell me what position the switch is in - presumably you are using positions indicated by 2,3,4 or 5, no? Still worth checking the lvars though to see if there is also an lvar that holds this information.

You have not assigned the brakes correctly in FSUIPC. You have assigned to send a single left/right brake control when entering an axis range using the right-hand side of the axis assignment panel, and that range is so large that the axis is always in that range and will never enter the range, so that they will not be triggered. To assign your toe brakes to an axis, you need to assign in the left-hand side of the axis assignment panel. And you still have AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET events logged, which indicates that your toe brakes ARE assigned elsewhere. Controllers are set to ON in P3D, so your brakes are either assigned in P3D or assigned in iFly (if that is possible). Please check where the brakes are assigned, remove those, and assign correctly in FSUIPC. Please see the User manual if you do not know how to assign in FSUIPC. What is strange though, in both logs, is that the value in offset 0x2F80, the AutoBrake switch position, is 1, which is Off, so I am surprised the autobrakes are kicking in at all. What is the position of the auto-brake switch? For the next logs (both tests), can you also move the switch through all its positions (so I can see if that offset changes correctly) and then leave it in the desired position and let me know what that is, to check it matches the offset value. With the brakes calibrated, I also see: So the autobrakes are being armed once you release the toe brakes, and some auto-brake controls ARE being sent, although not full and they decrease quite quickly over a period of 1 second. Without calibration: i.e. applied full and decrease slowly over a period of 33 seconds. So the autobrake is working, just not very well! I don't know what could explain the difference here. Please try assigning your toe brakes in FSUIPC to see if that makes a difference, and make sure the assignments are removed wherever they are currently assigned. Also, move the autobrake knob through its different positions, and let me know which position you are using. Also, with different positions to see if that makes a difference. John

In what section? You cannot uncheck in the axis assignment - once you have assigned your axes to a profile, all axes for that aircraft must go in the profile. You should be able to check/.uncheck in the buttons and keys assignments, and add new button/key assignments to either the profile or the general assignments. To remove an aircraft from a profile entirely, you have to remove the aircraft name from the [Profile.xxx] section (where xxx is the name of the profile) in your FSUIPC7.ini file. When assigning in FSUIPC, we recommend removing assignments in MSFS. MSFS2024 is more complicated, as you have also to check the aircraft specific assignments. John

Not with the myevents.txt file - that is read once when FSUIPC obtains a connection to MSFS, and it is not possible to read this again once the simvars have been requested. For the ini, you can force reloading of some sections - the buttons, keys, axis & axis calibration sections can be reloaded using the provided buttons in the panels. The parameters in the [General] section are mostly only read at start-up, but some are read on-the-fly (where documented). The auto and Program sections are read when needed, and the LuaFiles only populated on start-up but read when needed. The LvarOffsets and LvarsLogged sections are read once lvars are received (and I think maybe at least the LvarsLogged section may be ebing read every time lvar values are received, but I am going to change this). The InputEventOffsets section is read once Input events have been received (i.e. shortly after the aircraft is loaded).

Then where re your brakes assigned? And then what ha[[ened? That doesn't help much - I need to see the full logs. But it does seem that something is turning off the autobrakes You can also use a free file transfer service to show me the logs, e.g. https://filetransfer.io/ 2f80 just shows the autobrake setting as it is in the sim - nothing to do with reads. It is showing 1 (off) when calibrated, but going from RTO to off and back to RTO when calibrated, But hard to tell anything more when that is all that is logged. But looks lik it was never even set to RTO when calibrated, if the offset always holds 1. But, I really need to see the full logs to understand anything here. But it is certainly not FSUIPC altering auto-brake settings. May be the calibration is triggering iFly to turn this off, not sure. Where are your brakes assigned? And what happens if you remove the current assignment and assign in FSUIPC?

The log file shows that FSUIPC could not connect to MSFS. When did you start FSUIPC? i.e. Did you wait for MSFS to arrive at the main menu before starting FSUIPC? If so, you may have run out of simconnect connections due to another mis-behaving add-on. You should increase the MaxClients parameter in your SimConnect.xml - see What other add-ons are you using? Why don't you use auto-start?

👍

Looking at your ini, the only thing you seem to be using FSUIPC for is the brake calibration, where you have set quite a big slope (flattened at the start and stepper later), and rudder calibration. You don't have any assignments at all, neither axes or buttons. Are your brakes assigned in P3D, or in iFly itself? I am not sure why brake calibration could affect the auto-brakes. It is very large as you have so much logging enabled. Could you please just enable logging for the following (and disable the rest): Axis Controls, Events & Extras. Also, please add logging for offset 2F80 (as U8, and make sure to check to send to the normal log file). The file may still be too large to attach (your attachment limit will increase the more you post) - try compressing/zipping it. This will show if the auto-brake setting in offset 0x2F80 is being changed. If it is, we may need to enable IPC Write logging to see if this is being changed by an external program, but leave this off for the first log. It would also be useful if you could provide two log files - one with the FSUIPC calibration and the autobrake issue, and another with he calibration removed and the autobrake working as expected. You could also try with the toe brakes both assigned and calibrated in FSUIPC, to see if this makes a difference. Try assigning the toe brakes using the Send direct to FSUIPC calibration option. John

So your assignment in ProSim move the switch but the lights don't turn on? This would indicate that whatever you have assigned to is triggering something that moves the switch, but something else is needed to actually control the lights. However, if you are assigning in ProSim, you need ProSim support. I can only support FSUIPC, not ProSim. You said that ProSim has a WASM module to control the lights - did you install that? Your log file does show that you have an error in your announcement.lua file: That error indicates that you are requesting a callback on some type of event, but you have not provided the callback function to receive the event. John

Note that for PMDG aircraft, you probably need to use the custom controls that they provide. See the FAQ section on using PMDG custom controls (valid for P3D and MSFS). John

Your log shows the button press sending the key presses and then these key presses being received back, e.g. So your button assignments to key presses are working. Note that your log also shows that you are trying things too early - around 5 seconds after FSUIPC was started, but it hadn't fully started until a couple of seconds later. You should give FSUIPC a bit more time before trying to control the aircraft via FSUIPC. Ok, makes sense. Note you can also set logging for Events (Log -> Events), as well as Buttons & Keys, and also open the logging console window (Log -> Open Console), This would then not only show you what FSUIPC is doing, but what the key press is assigned to in MSFS (i.e. the event that it triggers). Anyway, good luck with MSFS2024...I don't use this much (still prefer MSFS2020 or P3D), but at least its a lot more stable these days... John

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