Heading Increment Bug (10 degree instead of 1) Explained

Great information, thanks. It’s a great option but how long for and at what cost?

Personally, I am unwilling, at the moment, to employ such work arounds and would much prefer that Asobo fix the core bug. Here are some of my reasons.

I do not need FSUIPC for any other purpose - it adds some overhead and more complexity. FSUIPC is still in beta and likely to change, when out of Beta it will cost money. Will Asobo now say buy FSUIPC to fix our ‘partner’ products (or more correctly, to work around basic HID bugs)? Given how overloaded the tech support guys are and the pressures from the community on so many fronts they may see this as acceptable.

The SDK is a rolling target. The sim is not mature and also a moving target. My own experience of FS2020 is that each and every update introduces some issues, and this looks likely to continue for a while yet. Updates themselves are difficult (for some of us who get download loops with this product and this product alone) and take a lot of time and frustration to complete. Conversely, Asobo might release a fix to this bug today for all we know (opimistic perhaps?).

Simply put, it is beyond my patience to spend time in FSUIPC/Lua while everything is in flux. FS2020 has some way to go before it could be considered stable.

I’m building up panels/hardware for X-Plane which is an older more mature product. The datarefs won’t change overnight, my plugins (probably) won’t get dorked by an update. It is worth time and effort because I know I will ENJOY the end result. Eventually, FS2020 will become a viable target for ‘tinkering’ I hope.

Good luck to all who choose to employ FSUIPC or vJoy to workaround this bug (I might yet if this is still a problem in a few months) but I think we should all expect, and pressure, Asobo to fix the basics.

We should use FSUIPC (and others) to expand the simulator in inventive and creative ways - not to fix the simulators handling of basic switches present in common peripherals.

8 Likes

I totally agree that the proper solution is for Asobo to resolve this bug in the sim. However despite multiple forum threads and Zendesk tickets I don’t believe they’ve publicly acknowledged the bug yet so I’m not sure if/when we’ll see this resolved.

I saw that others were having success with a few software workarounds so made the personal decision to try them. I had my Alpha working without the 10 degree bug using vJoy and Joystick Gremlin initially but I had a lot of issues getting vJoy installed and then it broke again after Windows the 2004 update and I couldn’t get it re-installed.

FSUIPC7 is out of Beta and available for purchase. I’ve used it in the past so decided to purchase and support the developer. We shouldn’t have to use 3rd party paid software to fix bugs in the sim but it is what it is for now. Hopefully this will be eventually resolved and I can remove the FSUIPC7 workarounds for my Alpha and Bravo controllers.

2 Likes

I’m not affiliated with FSUIPC (Pete and John Dowson) in any way, but I’ve used it in FSX, P3D, X-Plane, and now this sim. I didn’t use it in all those other sims to work around bugs – I used it to interface my peripherals with the sim.

I have a Honeycomb Alpha yoke, an VRinsight Combo II Boeing MCP, a PFC (Precision Flight Controls) throttle quadrant, and a good set of rudder pedals. Rather than use the sim itself for button and rotary mapping, yoke and rudder sensitivities and response curves, and complicated throttle mappings for all the different planes, I do everything in FSUIPC7 and use basically blank controller profiles in the sim. I automatically avoid controller problems when the sim gets updated, and do not have the heading increment bug, etc.

My point is that FSUIPC (or SPAD or some other tool) is pretty much required for home cockpit builders and for achieving an elegant solution for things like reversers, the TBM power lever (throttle and mixture combined), and control of things like the TBM lights.

So instead of thinking of FSUIPC7 as a workaround that you want to remove later, buy it – it’s cheap – and realize how powerful such a tool can be for the long term, even when a bug has been fixed.

Yes, you’ll need to learn a little bit of LUA programming to do the more advanced stuff, but it’s kind of fun to make the sim do exactly what you want.

1 Like

I absolutely agree that FSUIPC is a fantastic programme, should be supported and that it is a core in (MSFS) cockpit building and will be a huge advantage for those who have complicated setups (multiple controllers etc). No argument from me but, then, I do enjoy complication :wink:

When MSFS is a little bit more mature I will jump on FSUIPC and other tools to move my homebrew hardware over to the new sim. Learning Lua is trivial for me as I program in a few languages (as an amateur) and am a capable electronic home brewer. I am used to reading manuals and hunting down bugs/issues - I enjoy the challange but don’t tend to be an ‘early adopter’. At the moment I just want to use MSFS as a basic sim and enjoy the eye-candy and look forward to building that full cockpit that I will probably never build.

So, yes, you and I might buy FSUIPC and have our Honeycombs and whatevers working in short order. If an update dorks things then we will spend time and fix it and at least be able to make an educated guess about where to start and might even enjoy the challenge. BTW, you have some really nice hardware there Yeti :wink: You are obviously dedicated to simming and very engaged with the hobby (good on you!). Not everyone is though.

What about the many people who struggle with computers, hate installing anything new and just want things to work at least as well as advertised? Many of these folk struggle to install scenery or addons and the thought of doing this chills them to the bone. Gone are the bad old days when installing a serial joystick (or printer) required knowledge of flow control etc to have any hope of getting it to speak to the host.

So people go out and spend over £500 on an Alpha and Bravo (or a Knobster or a …) reassured that the sim will handle them without configuration - modern hardware, next gen software and both apparentely tested with one another during the ‘partnership’ program. MS/Asobo have gone to great lengths to advertise the sim and partner products to ‘newbies’, the wider gaming community as well as hardcore simmers.

Can you imagine if you had to install Spad or FSUIPC or become somewhat comfortable in LUA just to have a standard USB gamepad work in, say, GTA5? This would not be modding or improving the stock input routines it would simply be fixing a bug. There would be a riot!

I assert we should hold Asobo’s collective heels to the fire. Common peripherals should ‘just work’ in this post ‘Plug N Play’ era. Everyone should get full benefit of what they pay for and be able to use the sim their way, whether that is just for some fun or for serious modding and tinkering.

I really don’t mean to be disrespectful by talking down peoples knowledge of computing or their willingness to resolve bugs. I am trying to say Asobo should provide a product where such fundemental bugs are dealt with and people can get frustrated appropriately - by their choosen challenge (whether that be shooting a perfect NDB approach or learning C++ to build a panel).

I am not arguing the benefits of FSUIPC or other tools, I am just saying we should not let FSUIPC become an easier solution for Asobo than fixing the obvious issues.

Happy Flying Yeti :wink:

4 Likes

@T1gger65 - I’m trying to use these LUA scripts, but am a total noob at this. How do you add them to the FSUIPC7 INI file, and is there anything else to be done to make them work?

When I put the script for the Bravo in the install directory, I get the following in the INI file:

[LuaFiles]
1=hidBravoButtons

Do I need to add anything else? Just doing this doesn’t seem to work - FSUIPC sees all the buttons less than 32, but not the rocker switches that are above 32.

After some googling, I tried adding this to the INI file, but no luck

[Auto]
1=Lua hidBravoButtons

Any help appreciated

1 Like

My FSUIPC7 ini file has this at the bottom.
[Auto]
1=Lua hidAlphaButtons
2=Lua HidBravoButtons

[LuaFiles]

1=hidAlphaButtons
2=hidBravoButtons

the lua files are in the same install folder as the FSUIPC7 exe and ini file. When viewing the switch and button mappings in FSUIPC7 the Bravo rocker switches should show up as Joystick 64 or 65.

The other important part of the lua files is that they assign different offsets for the Alpa and the Bravo.
Alpha lua
– i.e. DWORD offsets 3340 onwards (3340 = ALPHA, 3344 = BRAVO)
ipc.writeUD(0x3340, buttons[2])

Bravo lua
– i.e. DWORD offsets 3340 onwards (3340 = ALPHA, 3344 = BRAVO)
ipc.writeUD(0x3344, buttons[2])

If you only have the Bravo than maybe try assigning the 3340 offset in the lua file instead of 3344 and see if that works.

I have both controllers and all the switches are being seen by FSUIPC7 as coming from joysticks 64 and 65 based on those 2 separate offsets.

3 Likes

Note: You might enjoy the latter posts in this topic:

[Huge performance hit when "breaking out" instruments]

I agree with you completely about MS / Asobo natively – and correctly – supporting the major peripherals, especially those of “partners”. Let’s talk about the Honeycomb Yoke as a specific example.

WINDOWS SUPPORT FOR MORE THAN 32 BUTTONS
As I’m sure you’re aware, this is actually a Windows issue for USB controllers. It only supports up to 32 buttons as of the current version of Win 10 and back. USIPC7 uses low-level device calls to read additional button information that Windows doesn’t expose. So the solution must be done above the Windows level.

SIM NATIVE SUPPORT FOR Asobo YOKE
So MS/A announced a partnership with Honeycomb and native support for their products. Honeycomb Yokes (Alpha) and Throttle Quadrants (Beta) now show up in the sim control panels. Good deal right? No. Read on.

SIM SUPPORT FOR “CONSTANTLY ON” SWITCHES
Honeycomb adds another sim complication because of their “constant-on” switches. Most joysticks and switch panels only send a command when the state of a switch changes. Honeycomb products, however, have their switch panels send a repeating “on” command for each switch, and that applies to whether the switch is in the physical on or off position. For example, the Battery switch on the yoke actually controls two logical switches – say logical switches 35 and 36. If the physical switch is off, then the yoke sends a continually repeating “switch 35 on” command. If the physical switch is on, then the yoke sends a continually repeating “switch 36 on” command.

EFFECT OF CONSTANTLY ON SWITCHES IN THE SIM
As soon as we map any of those switches in the sim, it appears to work correctly but causes a certain bizarre behavior. Everyone attributes that behavior to a bug in the Honeycomb yoke, but it really isn’t. Yes, in other sims that don’t have native Honeycomb support, you have to use the Honeycomb drivers and specifically interpret the constant on behavior to toggle a switch in the sim, but the other sims don’t suffer from a peculiar bug that is unique to this sim.

THE GLOBAL INCREMENT SPEED-UP BUG (HEADING, ALTITUDE, TRIM, ETC.)
There is a bug that is triggered by the Honeycomb constant-on switches, but it is also trigger by many virtual cockpit controls being clicked (incremented or decremented) too rapidly. It is NOT a Honeycomb-only bug.

For example, un-map all the Honeycomb switch panel switches (battery, alternator, etc.). Get in a plane on the ground and start it up. In the virtual cockpit, click the heading rotary knob (don’t use the mouse wheel – click it). Verify that it changes the heading bug by 1 degree. If not, restart the sim, and verify again.

Now click and hold it to increment the heading. You should see it begin to increment (or decrement) by 10 degrees with each click, and if you held it down, cause the heading bug to spin around and around even after you release the mouse. Now click the altitude rotary. It should increment by 1000 instead of 100, and go all the way to its limit. Click the trim wheel – and it will rapidly spin up or down to its limit.

CONCLUSIONS

  1. The native button handling for Honeycomb products works properly in the sim. It is natively using a (probably Honeycomb) driver that allows the sim to do the same thing as FSUIPC in regards to sensing the buttons above 32.

  2. Those buttons (switches) above 32 issue constantly repeated “on” commands.

  3. If you map those buttons to sim commands, they work as they should BUT…

  4. Mapping constantly repeating “on” switches OR manually doing the same behavior by rapidly clicking certain virtual cockpit controls (heading, altitude, trim, etc.) cause ALL controls to exhibit the global increment speed-up behavior.

  5. This is therefore a fault in the sim code, not a fault in Honeycomb products.

Since the problem is in the sim code, we’re stuck with waiting on MS/A (Microsoft/Asobo) to fix it. Until then, un-map the Honeycomb panel switches and use the mouse wheel to increment and decrement virtual cockpit controls.

If having the Honeycomb switches is absolutely necessary, for now you have to use FSUIPC or SPAD.

B

4 Likes

Brilliant - thank you @T1gger65. I actually have both the yoke and the quadrant (quadrant arrived yesterday!) but only had the quadrant plugged in when I was experimenting with FSUIPC - all to avoid the 10/1 increment bug. I’ll plug both in and match what you’ve got in the INI file here and see if that works and report back!

@T1gger65 - plugging in both the yoke and the throttle and updating the INI as you had worked a treat! Now just to figure out how to map all 48 buttons!!

Many thanks!

1 Like

Just a heads up – not all sim functions are available yet. FSUIPC7 changes at least once a month as the SDK and available “LVARS” change. So if you find something in the sim that isn’t yet available in the FSUIPC button mapping, you can always have FSUIPC send that keystroke to the sim for now.

Make sure to wade through the documentation and examples anytime you run across a problem. I’ve seen you lurking around the more technical threads, so I think you may enjoy dabbling with FSUIPC.

Be warned, however. There’s this thing that happens the first time you program anything that makes the sim behave how you want it. You get addicted! And it’s really bad.

If you start craving a fix, eventually you need to visit the FSUIPC forum. It’s sim specific and has a lot of users trying to do the same things you’ll want to:

[FSUIPC7 MSFS - The simFlight Network Forums]

Happy flying and programming!

B

2 Likes

Thanks for the heads up. Sending a key to the sim v mapping sounds interesting. I think I may be hooked already. How hard can this coding thing be, right??

Hoping I can at least sort out the 10/1 bug and maybe take it from there.

The quadrant is awesome though and really adds to my set up and looks the part

If I find myself on the FSUIPC forums, I’ll let you know!

1 Like

Please allow me to explain why this is not explaining anything and why this is not solving the issue.

  1. This 10deg increment bug is well known and well documented since at least 2004 (I’ve posted links to a few topics at avsim talking about this as an example). I remember perfectly well this problem back in the time and this was raised during FSX Beta and never acknowledged for nor corrected*

  2. I believe (but I might be wrong) FSX-SE did correct this problem, and/or Prepar3d and probably not until P3D2 maybe (but I might be wrong too - I lost track of these).

  3. If Honeycomb code is continuously sending their ON or OFF position state this is wrong too, and this is actually this kind of coding practice which is causing a lot of grief among simmers trying to mix different products together, like the RXP GNS/GTN with third party aircraft which gauge code does the same internally.
    .
    The “proper” way to code this sort of things to me is in the form of changed states, not absolute states. In other words:
    a) read FS simvar value
    b) if simvar disagree from your switch position, send a command to rectify.
    .
    Nothing more is needed, but because of the actual FS2020 SDK logic which is nothing else than the FSX SDK logic, and because this implies this implementation can only be done via polling for most of the monitored simvars, there could be a short gap between the state change in FS and the command issued by the hardware driver, which leads me to the next point:

  4. Asobo seems to be working mostly with a few Aircraft vendors and is putting them in the position of teaching Asobo how are the third party developers doing their aircraft in FS specifically. Because aircraft developers have limited exposure to the questions pertaining to inter-gauge/inter-vendor interactions because the aircraft is a whole in the FS SDK world, this gives little change to Asobo getting much expertise about these practical questions other vendors are confronted with daily for their products.
    .
    Furthermore, in working mostly (if not only) with aircraft developers doing FS products, this shuts the door to learning how the same things are better done in other simulators and therefore how FS2020 could benefit from doing differently. And this makes me revising point 3) above:
    .
    in XP11 for example, you can intercept commands and dataref state changes so that the “short gap” I was mentioning would be inexistent: the moment the state change, the hardware driver would immediately send the command to restore the state matching the hardware switch.

As a conclusion: there are two disconnected problems with the Honeycomb hardware and FS2020 in my opinion:

  1. FS2020 is not accelerating event inputs per inputs, but globally, which is wrong. Only the ones repeating should be accelerated, all others shouldn’t be affected.

  2. Honeycomb driver is trying enforcing the FS2020 state in sending a stream of events, instead of just sending the event needed to make the simulator state matching the hardware state when both disagree.

Both of these problems are independent of the other: Asobo should correct the implementation details of the acceleration system because it is problematic with or without hardware, and Honeycomb should correct the implementation logic so as to not hammering the simulator with non-stop events (for nothing 99.9999% of the time when no hardware switch changes position). At least, Honeycomb could easily implement a user selectable implementation: “Enforcing” (the current one) and “State change” (the proposed one).

*This shows how much FSX logic and SDK is still rooted in FS2020 in the sense instead of rethinking the simulator outside the box, the chosen path of taking the FSX code base and its SDK, removing what is not good and keeping what is good only works if you do have the knowledge about what is good and for this knowledge, you rather talk with a wider audience of 3rd party developers than just a select few.

PS: I feel compelled explaining a little more the little “rant” I’ve written just above in italic about the SDK. I strongly believe Asobo is doing a superb job with everything non gauge/system related in the SDK. It really shows new structures and logic, new implementation and modern interfaces and tooling. However, for everything gauge/system/modules, it is nothing else than FSX SDK in worst. Worst because not all is working yet, worst because the same bugs and limitations are therefore still there, worst because you can’t even re-code the deficiencies of the simulator because of the sandboxing approach depriving 3rd party vendors from enhancing the simulator internals. I find this a waste of energy trying to perpetuate these antiquated concepts inherited from the FS5 age and dating back from than 20 years.
.
For example, Asobo has built a solid JS/HTML system which really has deep capabilities for 3rd party developers, and this system is based on revolutionary concepts internally. Yet, they spend energy trying to “bridge” this with the antiquated constructs of the past so that 3rd party vendors can “easily port” their existing code… I’d rather them saying to us: “if you want to do an add-on, you’ll have to redo your code. We’re offering the choice of a future proof object oriented construct you can expand upon, or, a very low level down-to-the-entrails C++ access to the most basic internal structures. If you want anything which resemble the older SDK so that you port your aircraft faster, you’ll have to do it yourself.” The same reasoning makes me still wondering why it is they want to implement a XML gauge bridge into FS2020. Sure it will help porting existing XML gauge code, but why not just directly use the JS/HTML code path, ditch the old stuff and technological debt and let FS2020 fly higher…

4 Likes

While I do agree with most of your post, I will disagree there, though. A continous signal may be unnecessary most of the time, it does have merit, too. You do need this for the “START” position on the Alpha key switch because the duration of a state change does not suffice for starting a prop engine. Also, someone might be inclined to map a light test switch function to one of their toggle switches which also wouldn’t work nicely with a state-change-only solution.

2 Likes

Regardless of whether your explanation is correct or helpful (and personally I found it helpful and seems to tie in with what I’ve experienced) your final point seems to be the key one. Hence my foray into the world of FSUIPC!

although it might seem so, this is not true either: say start key on the “start” pos, send engine start event, key turned back on the “on” position, send engine on event.

If during the time you’re keeping the key in the “start” position, another gauge/module, or in fact just the user is sending an event to put it back in the “on” position, there is nothing much you can do even if you’re hammering the event queue in FS, because such event producer will get its slot and send the “on” event in the middle of the “start” events you’re sending.

And honestly, it would really take a convoluted case for this specific start key problem, and light test problem, to be interrupted by external gauge/module or user sending a contradictory event. In effect, when you’re starting the engine, you wouldn’t also trigger the “key to the ON position” with a keyboard shortcut at the same time…

Last but not least, if you’re polling at the gauge update notification rate (PRE_UPDATE in all FS from FS9 to P3D5), you won’t miss any state change when polling simvars because this is the rate at which all gauges and modules gets their turn in the loop, that is their opportunity to change such state you’re trying to monitor.

In other words, either you’re dealing with commands only, or states. The start switch deals with events only, the light switch deals with states. In both cases you don’t need to send a non-stop queue of events to the simulator, this is why I’m saying doing this is wrong. But in all cases, this event and simvar FSX model is not suited best. Instead, the XP11 system which is based on event handlers (command event handler, datarefs read/write event handlers) permits intercepting any such event and state change without any need to polling.

It is not rocket science and actually It is very easy to implement this in the existing FS structures and code logic (from FS9 to P3D5 at least): we’re actually augmenting FS with this facility for the RXP GNS and GTN implementation…

2 Likes

We’re on the same page, and that’s why I keep jumping in on topics that try to blame Honeycomb for what I call the “Global Increment Speed-Up” bug. Anyone proposing a solution to the Honeycomb switches or workarounds using FSUIPC or SPAD needs to admit its a partial solution. The real issue is the Speed-Up bug, and all you have to do is click and hold a virtual cockpit control to trigger the bug, which then affects many other controls.

You’re right – only the ones repeating should be accelerated, all others shouldn’t be affected." And there must be some kind of individual acceleration cancel logic as well.

POINT 2 – EVENT-DRIVEN STATE CHANGE LOGIC
Honeycomb has finally released drivers for FSX, P3D, and X-Plane that can turn the constantly repeating switches into toggles that trigger only when the switch state changes. Without that driver, the hardware is clearly sending repeats, so their new driver must be doing the state change sensing you describe elsewhere in your post.

In FSUIPC, I do exactly what you describe for many peripheral buttons, switches, and rotaries. For example, I use FSUIPC LUA logic to poll all 6 of the Honeycomb panel switches every 20 milliseconds and process them all, matching their state to the sim switch states, and only issue a command if a state doesn’t match. For the TBM lights, I created state change events for the yoke’s light switches, and again match the switch positions to the sim’s light switch state, and change them as necessary. This is important because of the TBM’s 3-position Off/Taxi/Landing light switch.

I’m happy having to use FSUIPC – I’m going to use it anyway so that I have better control of aircraft profiles, controller sensitivities, peripheral mapping, and stuff like that. Asobo should absolutely fix the Speed-Up bug because it limits virtual cockpit interaction for the general user.

Last, I feel your pain and share your bewilderment about the way they’re handling the migration from legacy to modern products. I believe they’re still getting a feel for what they need to provide attract and support third parties. I also believe they’ve still got a few more months where their focus in going to VR and Xbox. Six months from now, hard-core simmers and third party developers will likely get more of MS/A’s attention and love.

B

1 Like

Oh, yeah. Just realized that I was talking nonsense. Of course state changes would be sufficient. I was just thinking about how you circumvent the bug with Joystick Gremlin and its remapping. Completely different approach. I retract my statement. :grin:

1 Like

I sincerely hope so! Thank you for your encouraging support!

Just posting here to +1 the vote. I have a Thrustmaster Airbus Officer Pack and having the same issue. It’s strange that this set is marked as being compatible, but I had to unmap some buttons from the quadrant otherwise I would have weird issues when pressing esc whilst flying and retuning into the game - my flaps and spoilers would be completely out. Although that is now fixed, I’m having the increment of 10 bug. Hopefully Asobo see this and look into fixing it.

2 Likes

I am amazed at the amount of discussion of whys and wherefores here. Just understand that this is a clear cut case of PPP (Pi*s Poor Programming). Any controller that has at least one button or switch mapped in the way the video from T1gger65 describes will cause the problem.

1 Like