Similar MSFS 2020 issue: Works great on every version of MFS20
Bug description: Helicopter collective control is unresponsive after pause, assuming the aircraft was in the air when the pause happened. (Pausing on the ground does not cause any issue). The collective position is sent via SimConnect.
Repro steps:
Load H145 or H160 or a special version of H225
Take off into a hover
Pause (using ESC key), then press it again to Un-Pause
Expected: Aircraft is flyable
Actual: Collective flight control is blocked
To work around this, slew down to the ground (land) and then the sim resets something internally which allows the flight model to behave the same way
Hi @FlyingRaccoon. Thank you for looking at this issue, it is very important to us.
It is not fixed in 1.2.8.0. I just checked and the behavior is identical to the initial report.
Are you using a version of H145 that is newer than 400? I can upload a test package with the newer build if needed. I can’t see any reason why you’d not be able to repro this unless you are using very old builds which is an airplane with custom flight model. Maybe another reason is if you tested without any controller connected? I haven’t checked if keyboard-only is impacted. The binding COLLECTIVE AXIS should be set and then I intercept that.
A little more detailed repro:
Select H145
Start at KEDW on the runway
Pull the collective and enter a stable hover at 10ft over the ground
Hit ESC to pause the game, and ESC again to return
Observe that once you come back, moving your collective to 0% and 100% will have no impact on the vertical ascent/descent. It should be very apparent as you can’t descend to the ground at all anymore. There is also usually shaking going on as if the rotor is off-track and I don’t know why that would be (maybe it is a hint at something though).
Some users reported being able to recover by pressing F1 key, but I never found that to effect the situation. The repro should be 100% though.
This issue is probably related specifically to axis set in FS 2024. I tried porting to 2024 a more primitive collective controller using COLLECTIVE_INC / COLLECTIVE _DEC K:Events and it seemed to survive unpausing in flight in that case.
F1 key workaround is probably related - I imagine it sends just that event. Of course that doesn’t change the fact that it needs fixing, INC/DEC event method is more primitive and less accurate
I finally found the problem.
MSFS 2024 has an helicopter autopilot implementation.
When the player uses the pause menu, some of the modes are engaged to help the player maintain stability when he leaves the pause menu.
These modes are engaged until player inputs on the main helicopter controls are detected.
Since you are intercepting and masking key events to have your own implementation, this never happens and you end up stuck with AP modes enabled.
Also, this assistance is not enabled when you are on the ground.
By default, F1 triggers the THROTTLE_CUT event that you are not intercepting and is one of the watched event.
I will log a bug so this design is changed and accounts for intercepted events as this is a common practice among 3rd party developers.
@davux3 I don’t have a workaround so far.
Possibly, you can send some AP events to disable this but I need to find which modes are enabled and if AP events will be correctly processed in this unusual situation.
I guess sending the THROTTLE_CUT event and resetting the expected throttle position would also work.
I’ll keep you updated.
Thank You for the explanation. If I understand You correctly, this would mean in my case K: events increasing or decreasing collective are interpreted as user input, disengaging Asobo autopilot?
Just wanted to bring this topic up again. Now after SU1 is released, it still seems that this is broken. This is a rather major bug for all the Hype products.
Any feedback is highly welcomed.
Are there any situations outside of unpause when these modes engage, and can this be overridden or disabled? I find that in FS24 Asobo automation “corrects” my collective in Cera Mi-17 in periods of long climb because it seems to interpret lack of input in steady climb as me being AFK and automation reduces my collective to where it thinks it should be. I’m on stable, not on SU2 beta.
Not that I am aware of but I’ll have a look.
In the meantime, if you can demonstrate the behavior with a video showing the autopilot debug panel when this occurs, this would be helpful.
This occurs in freeflight with all assistances disabled, right?
I followed up on Your questions about assistances and found the issue, it was unrelated to Asobo autopilot logic after all. It turned out the keybinds I used to switch cockpit camera perspective to different crew stations (Shift+F2 / Shift+F3) where double-bound with collective inc/dec on keyboard ( F2 / F3 ). It turned out collective was occasionally disrupted because of input hiccups and/or user error.
Thank You for Your response, and sorry for taking Your time!