Honeycomb Aeronautical Partnership -- Please fix input bugs

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

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]

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

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

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:

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

I have and I’v commented on it.

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

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

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

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

Yes, not addressed. I filled a ticket to Honeycomb support. I did not get valuable feedback.

I suggest we all create a ticket to create awareness at Honeycomb:
https://support.flyhoneycomb.com/portal/en/newticket

Using Gremlin/VJoy is a workaround only. Setup is a pain and it requires another “tool” you need to run in the background before flying. This does not meet my expectations with regard to a “fully compatible” product.

1 Like

I’ve filled out a ticket on their website

3 Likes

very good and well done old chap but why the hell should we have to go all through that instead of having something that works out of the box. Shame on Asobo

This is an issue with MSFS that should be fixed in the next sim release. This is not a Honeycomb issue.

2 Likes

We shouldn’t have to !
But at least I’ve been getting ful use of my honeycomb gear since day 1

The truth is even when they do fix it I’m gonna stick with my solution because it’s so ■■■■ flexible and with a bit of imagination it’s fantastic what you can do with Joystick Gremlin when you start using the “condition’ functions!

I noticing its the sim itself I have a huge problem and like a lot of us out there have noticed its the buttons issue… and even 3rd party software doesn’t fix most of them… to prove my point delete all button associated to the yoke and throttle quadrant and you’ll see that it does work when setting a heading or Alt. The main problem is the button keeps repeating itself… They need to look at Microsoft X setup and have it set to a single action… and not repeat

1 Like

New Simer friend of mine used my hardware to try it out. We spent the first two hours getting it to work right. Out of the box Bravo was completley unsable. NOTHING worked.

Lack of export / import on key bindings + this issue… man, what a PITA…

Also quite dissapointing that there is no hint of aweknoledge ment from ASOBO regarding this.

1 Like

I e-mailed them several times regarding the issue and never got an e-mail back I posted it on there facebook no reply… I told them we spent good money on the honeycomb and these issues should be 1st inline. There problem is one is the axes is stuck in the setup, the buttons are repeating commands, to the simulator, I set them the old MSFS X setup and asked them to add the feature for single button press, the driver from honeycombs website is a bug in it as well… but as long as the upgrade the graphics everything to them is good… I just feel like they are saying hell with people spending money on new controllers… It sad when they won’t communicate with the people that spent money there product… I brought that up on a live stream and they ignore the question. But let see those world updates its going to be great with 90% of my honeycomb Alpha and Bravo is disabled and we can’t wait play.

2 Likes

Only problem with honeycomp is 10 degrees problem, and that problems is MSFS problem, not hardwareproblem. Same problem with other flight controllers too with on/off switch.

3 Likes

I’ve posted new information about this here: