Since returning to MSFS2024 a month ago, by far the most maddening experience I have had is intermittent functioning nose wheel steering.
I will spend a fair amount of time building the flight plan, loading passengers/fuel/cargo, go through checklists, get all ready to taxi, and then I can NOT steer out of my parking spot. Nose wheel steering linked to rudder is completely dead. The only way I can turn is through differential braking, and that does not provide anything close to the maneuverability needed to get out of a spot and avoid buildings and obstacles in my way. I rage quit the flight.
If I exit back to the map, load right back in to the same plane and just skip everything and try to go right to taxi, the nose wheel steering is completely fine and works as expected.
I have seen this on multiple planes. The Vision Jet and the Cessna 404 most recently.
My hardware binding are working fine. Flight control surfaces are moving as expected. I do quick preflight to have all covers, chocks, etc… removed before entering.
I have not found a bug similar to this description, and I haven’t found a magic variable that causes this to happen.
Is it a bug somehow related to trying to use ground services to pushback? Is there a bug with parking brakes, or with the linking of steering to rudder? Has anyone seen or heard of a way to make this happen and how to avoid?
I have had this recently as well. It was after pushing back and the tug disconnected visually but a ghost tug remained connected and stopped me using nose wheel steering. I managed to “fix” it by toggling pushback on and off again and all came right.
There is definitely something to this. I’m only using keyboard shortcuts. It seems more reliable that using pushback toggle can cause my symptoms to come and go. The fact that the cart sometimes does and sometimes does not attach means you have no visual way to tell what state the plane is in.
One thing making this more confusing to debug is that ALT + P for pushback explicitly means LEFT ALT + P. RIGHT ALT + P instead seems to trigger just the normal P shortcut, which is ACTIVE PAUSE, and that just adds confusion to the behavior. I was not explicitly noting which ALT key I was using, so this could have easily mucked up my previous debug steps.
I will monitor this and be very careful how I trigger pushback. This does appear to be a real bug and it’s also either directly or indirectly tied to the pushback bug I logged above. Whether one is causing the other is I guess for the developers to figure out.
I struggled with several weird control happenings until recently when I deleted all bindings and axes for mouse, keyboard and control peripherals - then started from there adding in only what I have for FS 2020. While doing it I was shocked at the sheer amount of bindings and their complexity as standard.
