What's Going to be in the Next Update

[CptLucky8]

@HalberQuacky

This is in no way due to a fault on Honeycomb’s part. “Accepted standards” in designing a switch which has an on/off position is that when the switch is closed (on) it stays closed until such time as it is turned off again, and that is exactly what the light switches and ignition /magneto on the switch on the Honeycomb do.

I beg to differ about this as well:

NB: please read my other post which link is a few post above for understanding the context of 2 vs 4 states switches

@CptLucky8

@hendis55

But why would anybody want to change the 2 vs 4 states behavior of the Alpha (and Bravo)? Is there anything you cannot do with the current implementation?

The main advantage is solving this kind of situation where the game you’re using the device with is not ment to receiving 2 inputs per switch change (one on and simultaneously the opposite one off)

For example I’ve tried using the Alpha on Project Cars II (why not using a -90/+90 yoke as a wheel!) and indeed I couldn’t assign switch inputs because of this.

It just makes sense to be able to have a switch alternating 2 states instead of 4 in some cases, and it isn’t hard to do via firmware changes or better, via firmware operating mode selection which you choose when powering up the device in pressing a combo of keys (this is a common low level firmware mode selection method).

In practice, it is easy: since each switch position is 1 or 0, it just takes disabling all OFF switch states as if the switch doesn’t exist at all. In other words, take a light switch for illustration (I don’t have the exact numbers in head but there are 2 buttons input per switch I’ll reference as button 10 and 11 below):

Current 4 states firmware mode:

• switch down sets button #10 = 1 and button #11 = 0
• switch up sets button #10 = 0 and button #11 = 1

Alternate 2 states firmware mode:

• switch down sets button #11 = 0
• switch up sets button #11 = 1
• the hardware never make a button #10 visible to HID, or if not possible, let button #10 be 0 always.

Although this would give some more possibilities to use the hardware with other software, this won’t solve the “constant” input triggering FS2020 to accelerate the knobs because this is a FS2020 only bug (limitation to keep this post politically correct but it is a game design error in any way you see it).