fix for the AP bug

heywooood

heywooood

Mayor Emeritus of Taco City
trouble with the heading/ALT AP bug?

watch this please Microsoft Flight Simulator | Heading/ALT Bug | Cause | FIX!! - YouTube

it makes me wonder when the author of this vid says that the way MSFS reads switches and buttons is as a continuous pulse - rather than as an open/closed position - does that 'stack'?
in other words - is it then true that the more you use the AP or whatever - on top of having the battery and generators ON and everything else - that all of these switch positions are continuing to 'ping' the sim? as he says
"on isn't just ON - it's ON ON ON ON ON" -for every switch and button. If this is the case - no wonder there are stutters and CTD's as there would be conflicts as the load increases over time - unless I'm not understanding fully how this works (entirely probable)
 
heywooood said:
trouble with the heading/ALT AP bug?

watch this please Microsoft Flight Simulator | Heading/ALT Bug | Cause | FIX!! - YouTube

it makes me wonder when the author of this vid says that the way MSFS reads switches and buttons is as a continuous pulse - rather than as an open/closed position - does that 'stack'?
in other words - is it then true that the more you use the AP or whatever - on top of having the battery and generators ON and everything else - that all of these switch positions are continuing to 'ping' the sim? as he says
"on isn't just ON - it's ON ON ON ON ON" -for every switch and button. If this is the case - no wonder there are stutters and CTD's as there would be conflicts as the load increases over time - unless I'm not understanding fully how this works (entirely probable)
Click to expand...

I don't think he's right. The problem as I understand it is exactly what he's saying, and it has to do with whatever driver is between the Honeycomb and MSFS. And I have zero idea why it's not fixed yet. But it's not a general problem with MSFS, why do other controllers work just fine?

He is right, the signal is getting sent again and again and again,.... from the honeycomb, nothing to do with MSFS. I assume the Honeycomb does this for compatibility with other games, etc.. Who knows? I'm not a driver designer. I'd trust him if he went in with some sort of probe, either hardware or software, and looked at the logic of the gauges and did some debugging and looked at the signals and responses. But he doesn't have a clue, it's all guessing. And he made up a reason from one anecdotal incident (the gauges turning off, I could think of other reasons).

So, I'm no expert either, but, it works with a mouse, everything works just dandy with my CHProducts controllers, and yet it doesn't work with the Honeycomb. If it was a general interface design issue with MSFS, you'd get the same result from all of them. This is ONLY a problem with the Honeycomb.

But, supposedly they are partners... Why isn't it fixed yet?

It has to be a difference in logic between the two. I'm sure someone familiar with controller and driver design could figure out immediately what's wrong, but, to your original statement, I really don't think this is the cause of stutters. And I don't see it as a problem with the way MSFS is reading controllers, the problem is the way the Honeycomb is sending signals. Gauge refresh rate IS a cause of stutters, that graphic update of a portion of the screen is a tax on the graphics engine and takes a lot of compute, especially since it's getting reflected off of surfaces. Polling a physical button controller should not be a cause of stutters, unless the driver is written really poorly. You'll notice his fix is bypassing the main interface with MSFS, and sending key commands.

Maybe it's an issue because really the turnable knobs should really be considered axes, but they're being used to send key commands? That would make sense that it wouldn't work properly, MSFS doesn't know what to do with so many axes, and since it's really an axis, it's sending a constant stream of commands?

For instance, if you're going to drive the trim, use the trim (-100 - +100) AXIS... do NOT send button commands for trim up and trim down. Using the axis works awesome as a trim wheel. I set up the unused throttle axis on my Logitech Extreme3D Pro controller as the trim axis and flying is soooo much easier.
 
ok well that seems to be what I missed, that he was talking about the honeycomb unit and not MSFS program universally.

The bit about knobs meaning to be handled as axes rather than switches as MS has it does seem culpable. I don't know a lot about this stuff either.
 
I've often wondered how things like rocker switches could be handled by an application that seems to be designed to accept a one-time momentary input. It makes me glad that I've held on to my trusty (original) X52 for all these years. Every input is either an axis or momentary on.
 
I use toggle switches which are connected to MSFS through Leo Bodnar's Button Box Interface or BU0836X I/O boards. I have used either MSFS or FSUIPC software to assign/bind the switches to MSFS functions. The Landing Light, Taxi Light, and Pitot Heat switches all show animations of ON/OFF/ON/OFF continuously. This seems like what would be observed if MSFS did continuously read the switch as ON/OFF/ON/OFF.

Also, I have run encoders, both my own and GO-Flight's through FSUIPC for autopilot functions. In both cases I get a 10 degree movement with a single turn of the encoder. FSUIPC allows for slow (single input) and fast (multiple inputs). In my mind I should not be getting a 10 degree movement.
 
well now THIS is interesting. John, are you inferring that it is in fact the MSFS program and not the programming of the peripherals that is unusual or somehow 'at fault'?

do you know whether this kind of continuous reading of switches and knobs could cause the program to be overworked in the background? could the effect of a user changing the settings of so many
switches and dials over the course of an hour long flight or more have a 'stackable' effect on the simulator? or does it even matter if the status of these switches and knobs are changed...

Further - if this is the case, would it be considered a core component of the software and therefore difficult to change at this stage without breaking a ton of other code..?
 
heywooood said:
well now THIS is interesting. John, are you inferring that it is in fact the MSFS program and not the programming of the peripherals that is unusual or somehow 'at fault'?

do you know whether this kind of continuous reading of switches and knobs could cause the program to be overworked in the background? could the effect of a user changing the settings of so many
switches and dials over the course of an hour long flight or more have a 'stackable' effect on the simulator? or does it even matter if the status of these switches and knobs are changed...

Further - if this is the case, would it be considered a core component of the software and therefore difficult to change at this stage without breaking a ton of other code..?
Click to expand...

I am not programming savvy or literate enough to answer your questions. I am merely stating what I have observed in my simulator cockpit. I am using common I/O devices that work fine on FSX though P3D V5. Since I have some of the switches assigned or binded via MSFS and others via FSUIPC, I will have to check to see if the ones mentioned are MSFS or FSUIPC. I will do that shortly and get back with you.
 
@Heywooood, I had the taxi and landing lights set to TOGGLE LAND LIGHTS and TOGGLE TAXI LIGHTS through MSFS. When I changed the Landing Lights to FSUIPC it quit going ONOFFONOFF. The taxi lights continued to behave in that way. So, it seems to be something via MSFS. Since MSFS doesn't allow a setting change when the switch is returned to OFF, I had to use the TOGGLE function. With FSUIPC I was able to set the landing lights to ON and then OFF on release, like a real world switch would work.
 
I'm not tech savvy at all - but this conversation is very interesting. Hopefully someone with a clear understanding of this stuff can chime in at some point.

What it's leading to - If I am reading this right - is a question about how MSFS handles control inputs from the user, and why it is handling them this way.
Also there might be a question as to how this all affects the simulation's performance. Is it possible that this is a problem and could it be causing some of the incompatibility and even other more serious problems folks are having with MSFS?

Is that a fair assessment of what we're looking at here?
 
MSFS has to be, at least for some inputs, continuously poling the switch positions. A button is a one time input. It works well for a toggle. A toggle switch is continuously OPEN or CLOSED, (ON or OFF). I know that in programming either status change or endless loop poling of switch positions can be used. FSUIPC must only send a status change, while MSFS is constantly poling the TOGGLE state. If the switch is OFF, it is tuned ON. If it is ON it is turned OFF, thus the constant animation of the switch moving from OFF to ON and back, when using a toggle vs. a button.
 
Thank you for taking the time to explore these conditions and follow up here on this topic. I'm pretty sure we all want the new sim to be all that it can be. As my own use for it is fairly pedestrian (all I want to do is fly short, VFR hops in conventional AC with minimal overhead) most
of the problems I hear about pertaining to IFR, auto-pilot, VR and peripherals do not apply. But like everyone else I am keenly interested in the success of the sim going forward. Expectations seem higher now than they were for FSX and I don't think I'm alone in thinking those expectations and the vitriol around them are what torpedoed FSX so soon after it was launched.
MS Flight suffered the same fate even faster than that.
Here's hoping discussions like this one, whether it is completely on target or not, can help in some way with the ongoing corrections yet to be made to MSFS2020
 
Then that tells me that the optimal design for a peripheral switch that would normally be a toggle should be run through a board that actually sends a momentary signal. Let the peripheral do the polling with firmware and hardware that are optimized to take that load away from the application.

Anybody got the number to the Logitech engineering dept.?
 
You must log in or register to reply here.
Back
Top