Honeycomb Aeronautical Partnership -- Please fix input bugs

Bug Reporting Hub Resolved
, ,
61

Ok this may help you Alpha Bravo users
This took me 6 hours to figure out and set up but now I have full functionality of my Alpha and Bravo devices.

I fly only GA aircraft so this will probably need to be modified a lot for airliners

You need vJoy setup as a 128 button controller
You also need Joystick Gremlin

First open Joystick Gremlin and load the below linked profile and make sure the green activate icon is on
Joystick Gremlin Profile!

Start MS2020 and create the following profiles
Note that for the sake of trouble shooting ensure that no buttons are assigned from the default profiles.
Your profiles should looks exactly the same as below; make sure it works and then start adding your own personal preferences

Alpha FS2020 Profile
This profile suits all GA aircraft

Alpha 1
Alpha 11121×648 79.3 KB

Alpha 2
Alpha 21125×562 63.6 KB

Notes
Button 1 is used as a “Shift key” so I can use buttons on the yoke for two different functions
So the normal “Toggle Smart Camera” is accessed by holding down Button 1 (Shift) and Button 6

Shift button 5 opens ATC window
Shift is also used to select ATC options 1 to 4 using the hat

I use the alpha buttons 9 & 10 to increase and decrease the altitude
I chose not to use the Bravo dial for this function as it makes it easier not having to rotate the Bravo dial so much when adjusting VS and IAS speeds

Looking at the profile you can see the other personal assignments used

Bravo Profile
Note that this profile is setup for a single complex engine plane like the Cessna 208b
I’ve created different profiles for the Cessna 152 and TBM as their Power Management requirements are different meaning you use different throttle, prop pitch and mixture levers but the below can be used as default setting which can be copied and adjusted by adding or subtracting the relevant Power Management Joystick axis as required

Bravo 1
Bravo 11472×657 103 KB

Bravo 2
Bravo 21483×217 30.4 KB

Notes
I have altered the functions of the left rotary switch
When in the below positions the increase/decrease dial changes the following in the sim

  • The labelled ALT position is now IAS (Flight Level Change speed bug)
  • Labelled VS & HDG are still the same
  • Labelled CRS is CRS1 (Works in the 152 steam gauge)
  • Labelled IAS is CRS2 (Works in the 152 steam gauge)

vJoy Profile

Vjoy1
Vjoy11077×561 56.7 KB

Vjoy2
Vjoy21074×409 46.6 KB

Vjoy3
Vjoy31074×525 46.8 KB

I wish MS2020 had a way to export profiles!

Final Note
When starting a new flight you are best to do a cold start and move ALL switch on and then off
This ensures the Sims functions align with your buttons

If you do a hot start you may find that you have to double activate a switch to realign the controller switch with the sim eg if your with a hot start the parking brake is on by default so if your switch was in the off position you will have to flick it on and off to make it align with the sim

8 Likes
62

This post is gold! I’m slowly but surely getting there. I’m on the step of figuring out what is continously on. A lot, apparently. Also, sometimes there is a conflict when setting buttons using the on/off option inside MSFS. It seems to work better if you choose the “set” options ex. “set nav lights”. Need more confirmation on that though. Thanks again for your post.

63

You might want to also vote for this other topic*:

Heading Increment Bug (10 degree instead of 1) Explained

*NB: this is a link to my comments in the discussion explaining why this is both a FS2020 and Honeycomb problem in my opinion

1 Like
64

Yeah in Gremlin when setting up a switch press and then release macro, it’s really easy to forget to change the default press to release on the second command; leaving a press press macro which continuously leaves the vJoy button pressed down

65

First have HC-TQ, have not configured/tried any of the buttons yet. It arrived last Tuesday, 1-5-2021.
Fixed Throttle 2 bug, and setup different profiles for the planes I fly except C172 and TBM-930. Lights work.
However, I am not going to do ASOBO’s work for them, since that is not my job. They will fix it, or they will ignore it. If they ignore it, all aftermarket products will not work as advertised. It’s like the SDK, work in progress. I suspect, they will take this issue and fix it, just have no clue when. Not life or death for me. I can always do it on keyboard/mouse.

66

Thanks for the work around ! but we wouldn’t have to resort to these for a fully supported gear by Microsoft .

I was excited to move on from P3D to have multiple programs open at the same time to run a sim, apparently MSFS isnt’t any different
 between this, live weather and the FD which doesn’t move without auto pilot. Its abysmal.

1 Like
67

Agree!
Which is why the focus should be to get it fixed at source, by MasoboS

68

Agree!
Nice visuals are only one part of what it means to actually be a next generation sim.

I find it quite strange that MSFS has built in profiles (E.g., for the ‘partner’ Alpha) but using that peripheral dorks basic input.

MasoboS really need to sort this and they need to sort it before the plethora of peripherals in development are released just to disappoint.

1 Like
69

Exactly
 its really disapointing how poorly these devices are configured considering they are “proud” to call Honeycomb a partner. Honeycomb isn’t to happy about it either from my email conversation with their product manager.

The focus is on visuals, and console players. It seems optimized for x-box controllers from a peripheral stand point.

And the number of bugs ported over from FSX, 10 year old bugs
 I don’t know where to begin.

They need a hard reset and focus on basics. Fixing the flight models (more bugs found every day) streamline inputs and peripherals, improve the SDK and documentation, Then go back to work on the pretty stuff. 3rd parties are taking a risk developing for this right now IMO, its in such a poor state and locked down, be taking a risk putting anything on the market place. Not suprised Carenado jumped right in, they kinda are the fast-food of flight sim-addon’s.

1 Like
70

You guys want to hear something that will upset you? Pop on over to X-Plane with you Alpha yoke and Bravo throttle. Guess what? EVERYTHING WORKS PERFECTLY! I’m sorry Asobo you guys are dropping the ball big time with these two pieces of hardware. Further: In, the 172 for example, the Amps meter is NOT broken, you CAN actually lean the mixture properly, no heading bug. I hate to kick a man while he’s down but you guys have to get on this right now. It’s inexcusable.

5 Likes
71

Hello Mr Slaarti (Bart Fast, I assume?),

There is another update ?

AGREE!

My Alpha is a pleasure to use in XP but more to the point it ‘just works’ and adds heaps to the sim experience- I can not say that for MSFS. When Amazon give me my Bravo I strongly suspect it will work with XP11 with minimal fuss and probably no frustration.

At the moment, MSFS is making XP shine even brighter.

I still hold the hope MasoboS will get all these teething problems sorted but as time goes on 


1 Like
72

You want to hear something misleading? Read posts like this one.

But if you want to hear the truth, then go to the official Honeycomb site and read how you have to download a Honeycomb application to change the constant-on button / switch behavior, and do other things to make it work with X-Plane. The link is at the end of this post.

Now, it’s true that the constant-on switch behavior caused a problem, but as of this date (mid-January), the Honeycomb driver allows you do the same configuration change for this sim. They even have template setup files that make the change easy.

This is a Honeycomb issue, not an Asobo issue.

[https://support.flyhoneycomb.com/portal/en/kb/articles/configuring-the-alpha-flight-controls]

73

I also think that Honeycomb needs to change this. Even if it would be caused by Asobo the workaround is easy to put in place by Aerosoft or Honeycomb. I do not understand why I small and agile company disregard the demand of their customers and fix this.

And with regard to X-Plane:
I am a real live GA pilot. I tried X-Plane and MSFS. If you have tried MSFS you do not want to go back to X-Plane. It simply does not lookalike the real world from above. Only missing peace is a solution like RealityXP for GNS530/430.

1 Like
74

This kind of gets back to a business concept called “core competency”. Honeycomb has made itself a place in the market selling input hardware. Asobo is in the flight sim business. It is therefore Honeycomb’s job – and their core competency – to make their product work for their target customers. If that means creating a custom driver that Asobo (or Windows) silently loads, so be it. It’s still on Honeycomb to do it.

That being said, Asobo’s core competency is the flight sim, and it DOES have an input processing problem that is affected by Honeycomb’s constant-on switches. It is also triggered by mouse clicks and holds on the controls in the virtual cockpit, so it is not hardware specific. It’s call the “increment speed-up” bug, and it is triggered by clicking various cockpit controls to increment or decrement them. If you click and hold, or you click too rapidly, it causes the speed-up logic bug on many controls at the same time. Symptoms include the heading changing by 10 degrees instead of 1 degree, the trim running all the way to the stops, etc.

So Honeycomb needs to fix their problem – and they have via a new driver / application that lets you redefine the behavior of the switches. And Asobo needs to fix their speed-up bug. It’s only after both parties do their part that the typical sim user will have what they need.

2 Likes
75

Really?

Why do you think it is abnormal for hardware to to send a constant high or constant low to the sim?

Yet, the alpha yoke works without any setup in XP11. I never had to download anything for XP11 and it works as advertised.

You are conflating configuration and customisation in XP with a well known bug in MSFS. You are not even wrong :wink:

76

I agree, see below.

Why don’t you take a few minutes reading what is already written about this?

Heading Increment Bug (10 degree instead of 1) Explained

NB: this is a link to my comments in the discussion explaining why this is both a FS2020 and Honeycomb problem in my opinion. You might want to also vote for this other topic

1 Like
77

I have and I’v commented on it.

Again, why do you think it is abnormal for hardware to send a constant signal?

78

Do you mean other than the following I’ve written in this other discussion (out of the context it might not be as understandable though and I encourage others to read the full post):

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.

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)

I mean sending a stream of events for nothing is already taking resources for nothing. The simulator receiving a queue of events must treat them and although it shouldn’t be much work in itself, it can cause multiple problems in the end (in addition to the acceleration bug inside FS2020 and triggered by this).

For example treating x number of events could be just enough events processing to make the simulator skip 1 frame (terrible in VR). Some of these events could be coded internally with the use of a mutex and while it is held, another part of the simulator is waiting for the mutex release and can’t make forward progress. And I’m certain if I spend some time I’ll find much more.

In essence if is just a better practice implementing such things as state change event based instead of sate polling based* and this might even be more relevant when the simulator will be even more using multi-core and DX12 when thread sync is paramount and any external device causing a thread to halt is not good at all.

Update: I’ve added the missing words. It is “state change event based” instead of “event based” which could be misleading. However there would still be “polling” because the hardware driver would read the FS2020 simvars each frame in order to check whether hardware state and software state are disagreeing and if so, the hardware driver would sent the event to trigger the state change. In this case, reading in a polling fashion is lightweight compared to writing (what the current stream of events is doing).

I believe the best way to deal with this though is still the way X-Plane is doing in offering the capability to attach an event handler intercepting each state change and the capability to overriding datarefs (which would also make feasible products like the RXP GTN - it is not a WASM problem but a SDK feature problem). With these, any hardware change would send an event, and any simulator change would make the hardware send an event if both disagree. It is equivalent to what you’d do in software with a signal/slot approach.

3 Likes
79

In the new sim update, this problem isn’t even mentioned, I guess the Honeycomb Bravo isn’t fully compatible as Asobo claims ?

2 Likes
80

Definitely not without applying one of the 3rd party workarounds
Using vJoy with joystick gremlin for example does how ever allow you to create profiles that allow you to fully utilise your Alpha & Bravo but it is a pain to set up BUT totally worth it once done