Closed FSFlyer closed 3 years ago
Do you use a button for braking? That is the only way I could re-produce.
I can confirm the same issue using a brake pedal (Joystick R-Axis Z-) rather than a key for braking. Seems to have started with an update to the dev. version yesterday 5/9 and still exists with today's (3bcf31e). First time I've encountered this issue. Max braking will deactivate even while parked at the gate but also any other time the pedal is pressed.
Also can confirm issues. Current setup is key bound breaks (Left and right) as soon as key is hit, max breaking is deactivated. Not sure if this is meant to happen all not, started only setting max break and hitting T.O Config while starting the roll on the runway.
Also see #3042 and #3546 The issue is that the current keybinding for brake, brake left and brake right automatically resets the state of the autobrake (as already pointed out by @MStallen in #3042). At this point I see the following possibilities:
I do understand the technical difficulties. But in my view (not using a TCA), this is a step back. We already had a working autobrake setting, which doesn't care about brakes during taxi. And now it's like a few weeks back. I don't know how many people own a TCA. Well, I guess I have to live with it. Or we implement a configuration (EFB) for those who use TCA throttles.
I have to say I cant replicate this issue with an axis bound to my pedals. can someone else that has this problem confirm it also happens when an AXIS is bound for braking?
Good question. I have just a button assigned to brakes.
i have same problem + seatbelts sign not working + crz prog change when changing altitude during climb
I do understand the technical difficulties. But in my view (not using a TCA), this is a step back. We already had a working autobrake setting, which doesn't care about brakes during taxi. And now it's like a few weeks back. I don't know how many people own a TCA. Well, I guess I have to live with it. Or we implement a configuration (EFB) for those who use TCA throttles.
This. I fixed the bug the first time because it was so annoying. TCA users with the extra module that implements the auto brakes are definitely in the minority and existing behavior should never have been broken to satisfy that case. Presumably, the workaround for the TCA case would be to bind the control to the local variable that A32NX uses (or was using).
The issue is: even reverting to the old state wouldn't make the situation much better (besides the "ON" light). Take a look at the screenshot from the current stable version We have the light but the actualy variable the controls the autobrake system is 0 (should be 4 for RTO). That way we will not get an effect of Autobrake MAX at all. One could say that with the current state at least we see that it's deactivated... But I agree it's annoying and I still don't understand why the brake "button" binding does that. However, I'm already looking into a way to force the sync again so we don't lose the setting when braking.
Thanks @geoffda and @Saschl for your comments. I just feared, that this would be the state for the next weeks/months. And then disappears in the deep darks of the issues section. I didn't know that the autobrake actally wasn't activated, even with the light on. Never made a rejected takeoff... lol
It's good to know, that there is someone still thinking about how to solve this. I hope there's a work around all can live with.
I have a solution for my system wuth a VrInsight Combo
On the Combo I assigned 3 buttons (FSUIPC.ini param 1,2 and 3 for the LUA) for the autobrake setting and they run the next LUA:
LastAutoBrakePos = ipc.readUB("66D0") if ipcPARAM == LastAutoBrakePos then ipc.writeUB("2F80",1) ipc.writeUB("66D0",0) ipc.control(32802) elseif ipcPARAM == 1 then ipc.writeUB("2F80",0) ipc.writeUB("66D0",1) ipc.control(32803) elseif ipcPARAM == 2 then ipc.writeUB("2F80",0) ipc.writeUB("66D0",2) ipc.control(32804) elseif ipcPARAM == 3 then ipc.writeUB("2F80",0) ipc.writeUB("66D0",3) ipc.control(32805) end 32802 = 34=MobiFlight.XMLVAR_Autobrakes_Level_OFF .... .... .... 32805 = 37=MobiFlight.XMLVAR_Autobrakes_Level_MAX in my .evt-File
Also I programmed my brake-button in the FSUIPC-ini file: 313=PA,1,Cx01002F80,x00 -{offset byte set, offset 2F80}- 314=UA,1,Cx01002F80,x00 -{offset byte set, offset 2F80}- 315=B66D0=3 PA,1,C32805,0 -{:MobiFlight.XMLVAR_Autobrakes_Level_MAX}- 316=B66D0=3 UA,1,C32805,0 -{:MobiFlight.XMLVAR_Autobrakes_Level_MAX}-
If I push or release my brakes the 2F80 goes back to 0 (because breaking sets this to 1) and if 66D0 was still on autobrake-max it reengages C32805 (XMLVAR_Autobrakes_Level_MAX) I use the value in 66D0 for my Autobrake-indicators so they match the A32NX
Works like a charm for me and autobraking is actually working
Good news is that the inclusion of brakes + hydraulics will prevent this from happening as we handle the event ourselves. Depending on the progress I'll check whether we'll have an intermediate solution or not.
This is more of a positive side effect than a correction from hydraulics change.
Anyone has some knowledge about this in systems.cfg? autobrakes_disabled_on_braking = 1
You can do that. But then, the autobrake won't disconnect when you manually break after landing.
Let's not do that then :) I guess we'll solve this definitly when doing our own autobrake
Aircraft Version
Development
Build info
Describe the bug
Following standard procedures for takeoff, auto brake is set to Max and whenever I apply brakes during taxi, the auto brake deactivates (essentially how it works on default MSFS aircraft)
Expected behavior
Autobrake Max should remain on during taxi on the ground when taxing to the runway.
Steps to reproduce
References (optional)
No response
Additional info (optional)
No response
Discord Username (optional)
No response