John Dowson

As with all other users who report this, your key validates just fine. I will pm you a key file and try this. Save the key file to your FSUIPC installation folder, then re-run the installer and validate the key by clicking the Register button at the end of the installation process, If it validates, then the only possible reason that you are unable to register is that you did not enter the details correctly. If it does not validate, and you have installed the required VC++ redistibutables, then it can only be your anti-virus software blocking the validation - please check that.. Can you PLEASE respond once you have done this. I would like to understand why so many people are having this issue so that I can update the documentation accordingly, but nobody is responding. John

Do NOT manually edit the [LuaFiles] section. This section is maintained by FSUIPC. Your script is never running, so the offset will not get updated. Before you write the axis value to an offset, check if you can use either offset 0x3416 / 0x3418. If you just want notification that the brakes are being used, you could also try the 'brake being used' flag in offset 0x32F9. So check these offsets first. If none of those offsets are working, then maybe consider using a lua script. If those offsets don't work and you want help with a lua script for this, it would help me if you could provide a log, with logging set as previously advised. Note that I am now on holiday until September, but I should have time to look at this again on Monday if you need help with a lua script (so please provide the log file before then). John

👍

You can do that but I wouldn't recommend it, especially if the app connects to MSFS or FSUIPC. The batch file will also be overwritten/replaced whenever you update FSUIPC7 as well, and you would lose any changes. FSUIPC provides facilities to start other programs (registered/licensed version only) - you should use that. These facilities provide options to delay the start of the program until MSFS has started or until an aircraft is ready to fly, can also close or kill the program when MSFS exits, as well as other options. See the section Programs: facilities to load and run additional programs on page 44 of the Advanced User guide. John

The log looks good! I think the lesson from this thread is that if you want to calibrate any axis in FSUIPC for the iFly 737, then you also need to have the axis assigned in FSUiPC using the send direct to FSUIPC calibration option, and not the send to FS as normal axis one. I consider this topic closed now (unless you have any more issues). You can remove the logging now, including removing the [Auto] section to start the lvar logging lua script. Regards, John

By "switching off", do you mean that FSUIPC exited? You log file shows that FSUIPC was running for just under 6 hours and then exited as MSFS was no longer running. If MSFS was still running, you can try setting the DisableMSFSMonitor ini parameter to Enum or Yes. From the Advanced User guide: John

Thats good news! I will check your logs tomorrow, but I would suspect it was the change in assigning the toe brakes using 'direct to FSUIPC calibration', instead of 'send to FS as normal axis'. I cant see how the other axes assigned in P3D could cause this, especially as it was working without the toe brake axes being calibrated in FSUIPC, and you only get the issue when the Toe brakes were calibrated. Some (complex) aircraft dont play well when using FSUIPCs axes calibration facilities when an axis is assigned in P3D or in FSUIPC using 'send to FS as normal axis'. For such axes, you should assign using 'send direct to FSUIPC calibration' and calibrate. This is also the better/preferred/recommended method anyway. The underlying issue is complex but due to conflicting priority levels used to trap and mask events in FSUIPC and the actual aircraft. John

Is FSUIPC7 running? Is it connected to MSFS? Check your FSUIPC7.log file... You can also try adding Init3308=13 to the [General] section of your FSUIPC7.ini file. This will pre-populate offset 0x3308 with the version number for MSFS2020 (13) which is needed by some add-ons. If using MSFS2024, set this to 14 - although some add-ons not yet updated for MSFS2024 may still require this to be 13. Your add-ons must also be running at the same privilege level as FSUIPC7, so check they are either all running with standard privileges or all with admin privileges. There are also many other posts on connection issues with VAMSYS - check those. And if you still have issues, when FSUIPC7 IS running and IS connected to MSFS, AND you have added the init3308 parameter to your ini file, then show me / attach your FSUIPC7.log file and I will take a look. John

To log the lvars, please save the attached script to your FSUIPC6 installation folder: logLvars.lua Then add the following to your FSUIPC6.ini file: Before take-off, please again rotate the autobrake switch through the settings so that I can see the values associated with each setting. You can also now remove the assignment to list the lvars as it is no longer needed. John Later: I have also now added logging for the lvars when the OnGround flag changes,

But you assigned them using 'Send to FS as normal axis'. When assigned this way, the calibration is going to work the same way as when the brakes are assigned in P3D, i.e. the brake events are sent to the FS, then picked-up by FSUIPC, calibrated and re-sent. As I previously said, you should try assigning using 'Send direct to FSUIPC calibration'. When assigned this way, the calibration is done before the events are sent to the sim. Sorry if this wasn't clear, but can you please try that. There are several lvars related to the brakes/auto-brakes that look interesting: Maybe worth monitoring some of these. You would need a lua script to do this, which I can provide. I'll try and does this later today. But it is clear that offset 0x2F80 isn't being used, so you can remove logging for that offset if you like. I think this is because of the extreme slope you have now combined with the initial null zone. Once you have changed the toe brake assignments to Send direct to FSUIPC calibration, re-calibrate your brakes, giving an appropriate slope - look at the ini/out values as you are doing this, where the out value will be the amount of braking applied ranging from -16384 as no brakes to +16384 as full brakes. I would suggest starting with a slope value of 9 or 10: 15 is pretty excessive and won't give any breaking until the pedals are nearly 25% depressed, and effective breaking a lot later, e.g. 25% breaks when 5/8ths pressed. You can also reduce the initial null zone on the toe brakes to your preference - its the min value of the toe brake calibration. I won't worry about that if momentary... Isn't this always the case? Does the disarm light come on before you start manually breaking? I can understand why it comes on when you manually start breaking, but not if before. Any manual breaking will/should disarm the autobraking. But, from your earlier logs, autobraking WAS initially working when calibrated in FSUIPC, but only partially and only for the first second or so after touchdown, and then it looked to be disarmed. Anyway, the logging of the lvars should hopefully show what is occurring in more detail. A log of when autobrake is working/calibration disabled would also be useful, with the additional lvar logging. I will provide the lvar logging lua script later and let you know how to use this. John

Ok. I have updated the script available in the first post in this topic to accommodate for both reversed brake and rudder axis when necessary, and provided instructions on how to do so. John

That would imply that the rudder axis is reversed. Look at the rudderChange function, and find this: Then add a line to reverse the rudder after that comment, i.e. You could also add a rudderAxisReversed variable and do this on an if...then conditional if you wish, as is done with brakeAxisReversed. John

You could also try adding a null zone around the toe brakes, so any small changes (e.g. when using the rudder) doesn't de-activate the autobrake. Try something like: [JoystickCalibration] LeftBrake=-15750,16383/8 RightBrake=-15750,16383/8

The problem seems to be this entry in the registry, which has the same GUID as your TCA Q-Eng 1&2 device: This seems to be a phantom xbox controller and I think is related to steam. Try ignoring that device, i.e. add IgnoreDevice=0x28DE,0x11FF to the [JoyNames] section of your FSUIPC7.ini file. I have added this for you in the ini attached below if you would like to download and try that. Note this is what I also advised earlier when you had the same issue (see above). John FSUIPC7.ini P.S. See this thread from this comment onwards on this issue: Basically it only seems to happen when FSUIPC7 is auto-started by MSFS and when a Steam installation is being used.

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