Hi, I also have the issue arise when using the Thrustmaster Hotas Warthog Throttle, which has switches like the Bravo (and perhaps other peripherals). It goes away when I unplug it, and also when I don’t use the Bravo. I’m not defending or criticizing anyone, my point is that it isn’t just a Honeycomb issue from my experience.
Mark
2 Likes
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.
The sim does not deal well with any USB controller which has a switch that sends its state continuously, and Honeycomb is not the only controller which has the problem. There are other controllers which have switches that remain closed once activated that will cause the issue as well.
Asobo was certainly aware in advance that some switches on the Honeycomb yoke work that way. They designed a custom profile for the yoke that has control assignments for the light switches so that if you turn the Nav light switch “on”, the aircraft nav light switch moves to the “on” position. The same holds true for the other light switches, and the ignition switch.
In fact any yoke which has a center-off trim switch will cause the problem. If you press and hold the trim switch, and try to adjust the heading while the switch is depressed, you will find that it will advance by 10 degrees instead of 1 degree.
This is not a new problem. FSX had exactly the same issue with controller switches that send their state continuously, as did early versions of P3D.
3 Likes
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
1 Like
Ok, very much respecting the development experience in the people who’ve responded:
-
We all know, if the fix was simple, it would be fixed. There was no sneakiness involved here, communication about the issue has been above board
-
Having read through the SDK, I’ve realized that Asobo has very much been a vendor for Microsoft, with a specific set of requirements, including:
a. making sure the the product was compatible with FSX so development of products could be faster and older planes could be brought forward (oops)
b. That it had to follow guidelines for XBox - the sandbox and all the evils that the security it provides that stops developers’ abilities to write programs that can interact with MSFS
My point was, it is not “disgraceful” they haven’t fixed it yet and they have pushed it off, nor was there a single bit of “sneakiness” involved here. They are clearly working on it. If it’s not fixed yet, after all these years, there’s got to be a reason. In many ways, Asobo’s hands are tied, and it’s going to take time for them to untie the knots that are stopping them from moving forward in various areas of the code that they are working with. It’s not a new, from the ground up development project. This is new code running on top of and interacting with verrrrryyyyyyyyy old code.
A read of the description of the MSFS Flight Model in the SDK is quite enlightening if you read it with an understanding of them as a vendor for Microsoft, in terms of what Asobo is dealing with in some things in their contract around delivering this product.
And that’s not a hit on Microsoft either. They have their reasons, economic and global delivery and on and on as well.
And I still put the problem in the hands of Honeycomb as well. But, my bet is, the thought was “we’ll do it this way and force MSFS to change and catch up to the rest of the world in controller interaction”. Or, maybe they had an agreement beforehand it would be fixed, but, Asobo didn’t realize how much work it would be and is behind on getting that fix done. We’ve all been there. Well, not me, my projects are always finished on time 
Edit 3/21/21: The latest update of the SDK took out a lot of the language I am talking about in the flight model description
I imagine it was originally written to convince Microsoft it was the way to go, and then they saw my posts in another thread talking about it and realized “Eek!, did we really leave all that in there (X-Plane comparisons)? Quick, clean it up”. I wonder if my verbatim posts are still in that other thread? No matter…
1 Like
@FlyingsCool5650
I agree fully to your post!
I’m just citing it is an old bug just to illustrate as clearly as possible the main problem lies solely in the FS2020 code inherited from FS9 to get started, a bug Asobo might not have known until we tell them, but which multi decade old 3rd party developers like Pete Dowson or me know very well because we’ve been in this industry dealing with all simulators versions for a long time, and we’ve been dealing with such bugs patching the defects in the FS code.
Should they be more proactive with us, they’ll discover a lot of bugs in the FSX code I know about which I’m forced to recode at runtime (think detours/trampoline hacks) to make our products working as expected… For example the problem behind the F/D bars and the autopilot… This one is easy and rooted in the FS code since at least FS9 ( I know, we also detour this code for the RXP GNS and GTN 
)
Having said this, Honeycomb is also implementing their hardware switches in a way which is not expected (i.e 4 states switches instead of 2 states). It makes sense to do the way they do for a certain purpose, which is making sure external events can’t change the logical state of the switch in game which would be disagreeing with the physical switch. However, this prevents using the hardware with other games which are not expecting 4 states per switch, and I believe they should make it an option in the firmware without the need for a driver.
1 Like
I would agree that they could make the light switches an open (0) in the “off” position, but that would not help with something like the magneto switch, which would have to send a constant state in the “Left” “Right” “Both” position to work correctly.
Just to make it clear, switches don’t “send”, they “are”. This is an important point because it is not the hardware “sending” an event, it is the game “reading” a state.
And this is why I’m saying there are 2 sides:
- FS2020 input acceleration bug rooted in the code logic since at least FS9
- Honeycomb using 4 states switches (for a useful purpose) instead of 2 states switches (universal).
There is no other way to do for the magneto/starter switch than having a state per position, nothing to change there from Honeycomb. Once FS2020 corrects the input acceleration bug, it won’t be a problem.
The only ones that work properly for me are the landing light, and strobes. Nav, Beacon, and Taxi lights do not, though I did manage to get the Taxi lights half working with the Bonanza by using the “Set” binding instead of “Taxi Lights On” (or Off), but it works backwards, where up is off and down is on. Then again, I am talking about the Bravo TQS, not the Alpha Yoke, so that could make a difference as well, too.
Regardless of who is “at fault” (which I really don’t care about), I would just like it to be fixed so that I can operate my lights properly.
I haven’t even TRIED the autopilot functions, except for the altitude pre-select, which works well but only with adjustments of 1,000’ up or down, so if ATC gives me say, 4,500’, I have an issue. I can work around it by hitting the ALT hold button as I go through 4,500’, but I can’t set the pre-selector to that, just 4,000 or 5,000. And I think once I use that workaround, then I’m limited to X,500’ on the pre-selector unless I use that same workaround again.
It also “works” if my VNAV has a hold at that same altitude, at least when the VNAV feels like working properly and leveling off there, which doesn’t always happen. I’ve yet to figure out why it works most, but not all of the time, or even if it’s a bug or user error, though I suspect the latter. I think VNAV is only working properly in the WT CJ4 and the FBW A320 anyway, but I’m not 100% certain about that.
1 Like
@FlyingsCool5650, Tom I very much agree, but this does inspire a question… Is there a public forum or similar for Honeycomb support issues? If not, I think one should be created, and this would probably be the perfect place for it to live.
Thoughts?
I hope and pray that once the XBox version is “in the can”, then this nonsense can stop. And all evidence points to that actually being the case. The very existence of the Community folder on the PC version that doesn’t (and can’t) exist on the XBox version is indicative the MS has no intention of tying the hands of either their own dev team (Asobo), or third parties when it comes to the capabilities of the PC version of the application. If they were trying to make them “equal”, the directory wouldn’t even exist. But I for one am tired of being a guinea pig while they tweak with settings (best example I can think of is the LOD stuff) to get it right for the XBox version. But at the same time, that’s kind of the price we have to pay to have the XBox revenue available to further enhance the PC version moving forward. And I’m willing to pay that price.
I’ve said many times that I think people who want to run MSFS on an XBox are nuts, but it’s also a brilliant business move on the part of MS, and will provide many benefits for us hardcore simmers moving forward. So I hope shopping mall Santas are hearing “For xmas this year I’d like flight simulator for my XBox” for many, many years to come. Some of them as they get older and eventually have money of their own to spend might graduate to the PC version, and even go on to having real world careers in aviation, so it’s really win, win, win, win, all the way around for EVERYBODY.
Who are you calling old, buster???
I can’t speak to the existence of any up front agreements or anything of that nature, but I was told point-blank by a genuine Honeycomb employee that there were active conversations happening with MS/Asobo on doing whatever needs to be done on the back end software side to get all the issues resolved. I just hope it happens before I become genuinely old lol…
1 Like
If by any chance you can pass this information along then:
Heading Increment Bug (10 degree instead of 1) Explained - #298 by CptLucky8
1 Like
After downloading the next update, you will launch MSFS 2020, and 30 seconds later , a flame will shoot out of your PC and set all your controllers on fire.
2 Likes
@CptLucky8, I gave them some info regards the 1/10 bug, well really more questions than info. They sounded like they were familiar with it, but I don’t want to overstate the situation. It’s not like I’ve got some guy on the inside who is feeding me information, it was in the course of a tech support ticket dealing with a broken throttle attachment that the conversation came up, and it was just the guy who was helping me with that who indicated those conversations were happening and ongoing.
I must also say that I was VERY impressed with how they handled the broken attachment problem. With no questions asked (except for what’s my address), they sent a replacement handle, and even threw in a Honeycomb key ring that you wear around your neck like a necklace. No “send me your receipt”, or “where did you buy it from?”, or “when did you buy it?” or anything like that. Of course, given how new the product is, they know that mine is under warranty because none of them that are loose in the wild are old enough to not be under warranty.
Bottom line is they handled my problem like a boss. Well, the broken attachment problem, not the 1/10 software bug one.
2 Likes
That’s where it comes in handy that the Honeycomb on/off switches are actually two buttons each holding 0 or 1. You can see that in Windows’ calibration window. If the Set-bindings work backwards, just assign them to the opposite position.
Off topic I guess, but I haven’t been able to find an answer eslewhere: why does the honeycomb yoke have two switches for pitch trim, it’s like a single button sawed in half to yield two independent buttons,
That’s a replicate of what it’s like on some planes in real life. You must press both switches for effect. It’s a safety measure to ensure that one faulty contact doesn’t result in a run-away trim, a very, very, dangerous thing. It’s your choice if you want to go with realism or versatility.
4 Likes
I was wondering that myself - makes total sense.
They have mentioned in a past Q&A that they’re looking at adding a freeware section to the marketplace. That would actually put the PC and XBOX versions on somewhat equal footing - assuming Microsobo can streamline the publishing process so that freeware devs can get their stuff into the marketplace in a timely manner vs the currently excruciatingly long flash to bang times.
I’d really love to see them address the single core bottle neck / limited by main thread. I doubt we will see anything until Direct X12, but the fact a 5990X can only get a maximum of around 45-50fps in the Airbus A320 is a joke.
And anyone with a lesser CPU can barely hit 35fps at the best of times. I know people say you only need 30FPS, but the issue is there is some scenarios like looking around at scenery where its easily noticeable if you have 30FPS.
X-Plane on a similar build in a similar aircraft gets 60-70FPS.
1 Like
Good Lord, this thread’d turned into something like tech geek’s chitchat board ! So what would we get for the upcoming sim update ?
The main reason why XP would always win when it comes to FPS is that it’s just inferior to the MSFS in case of the maxed out graphics, hence the threshold at which your CPU ever gets tired is way too higher with it.
2 Likes