I realize the 100/1000 increment issue was in fact an annoying issue for those with external hardware that supported rotary inputs. A lot of people found work arounds to this issue by using 3rd part software to make sure no input was in a “CONSTANT ON” position since this is what caused the 100/1000 increment issue to begin with.
Now that they fixed this issue in the last iteration, they’ve managed to make rotary inputs completely useless.
Before, you’d get a nice ramp-up from 1-10-100-1000 depending on how fast you turned the dial (like the real thing), ever since the fix, this is GONE! Everything is now increment of 1 or 100 in case of altitude. It’s not fun going to 37,000 feet, 100 ft at a time.
Asobo? why are these kind of fixes just patch jobs to shut us up? You have enough REAL PILOT engineers and consults there to tell you this is NOT how inputs work. Yet you found some easy work around to limit all external inputs to 1 increment with no acceleration. Just to stop us from reporting the 10/1000 issue.
Can you sit down, and competently resolve this issue? Thank you.
Odd, acceleration still works fine for me and I would have thought there would be many complaints about this if it was a common issue…
Seeing you don’t give any details at all there isn’t much Asobo or anyone else can do about it. I can see right now it works fine on the stock 152 with both the Bravo throttle and Logitech panels.
Do real input knobs on eg the G1000 actually use this acceleration system, where multiple small rotations of the wheel will suddenly increase the amount of adjustment per rotation increment, then after some time of it sitting idle it returns to the original increment amount?
I have always expected that real avionics inputs have the amount of rotation directly, linearly related to the amount of change applied, and that the whole acceleration thing is thus wrong. But I might be incorrect?
(This is a serious question; not a real pilot but interested in learning and want to know more about real avionics.)
I don’t fly GA so I can’t comment on that. It used to work really nicely w/ the A320 Stock and A32nx if you made sure none of the switches were in always on position.
Since the fix, it’s limited to 1 increment per rotary click. Rotary encoders basically act like a switch which pushed over and over when you turn the dial.
On my own FCU using encoders there doesn’t appear to be any acceleration no matter how much or how fast I twiddle. I’ve actually only tried it in the 320 so perhaps I’ll try in a GA aircraft and see if it’s type specific.
That would make them a real chore to use for large changes.
My experience of G1000s etc is limited as most of my GA flying was steam driven and well over a decade ago, though from recollection they do accelerate. But I can certainly tell you on the Airbus they accelerate after a certain number of clicks within a given time period, couldn’t possibly tell you what the formula behind it is though - whatever they use it feels very natural and intuitive however!
Thanks, that’s interesting information to know! I find this surprising since it’s so difficult to dial in a specific number in the sim, having to overcorrect over and over for an acceleration that kicks in unexpectedly.
It’d be nice to know how they actually work in detail some day.
It doesn’t feel unexpected in real life, I can’t really explain it but it’s very progressive.
You’d have to really be monkeying around to have any issue selecting close to what you want even accelerated… usually even a fast spin of the alt for example will land it within a thousand or two of your intended target followed by a slower click or two to dial it in.
I think my disappointment is in the fact that it worked perfectly prior to the fix for the 1/10 increment issue (which was caused when any assigned switch was in constant ON position).
Now that I think about it, it’s possible that they had something originally that would be like if there is X number of input commands in Y amount of time, then switch from increment of 1x to increment of 10x. This would be considered an accelerated input. If you slow the rotation down, it would go back to 1x increments.
I’m also guessing the issue they ran into was when there is a switch in ALWAYS ON position, it is constantly sending commands (You can view the Console Log in say FSUIPC7 and see this event activity). Because there was a persistent stream of commands, any input, it would see it as an accelerated input and would only do 10x adjustments until you turned off this always on switch (which would stop the stream of commands).
The easiest fix for this issue? Just remove the accelerated option altogether, so no matter what, any input at any speed regardless of what other persistent commands are being sent, it would always be 1x.
Since the increment issue was also happening if you used the mouse to turn the knobs (scroll wheel), they figured this was the easiest solution to fix it for majority of the people as most people just use their mouse and not many people have rotary encoder setups.
The thing to note is this only effects how external inputs are taken in. If you were to hold down your mouse button say the heading knob on A320, it will start off 1x and then quickly ramp up to 10x. Just doesn’t do it when the input is external.
This is how I experience it currently, but doesn’t explain how acceleration is working for @Yuudai5178 with his bravo throttle and logitech panels if the feature was just removed.
Maybe it wasn’t removed (I’m just guessing) but limited to work with supported hardware?
I use a Leo Bodnar boards to make custom panels. Always have and usually work just fine (And did prior to the fix). I think other people reporting issue either use Arduinos or similar boards like Leo Bodnar’s. So issue could be limited to custom stuff? Which kinda sucks and doesn’t give me a lot of hope.
One thing I’ve noticed is how little (to none) Asobo/Microsoft talk about MSFS support for home cockpit builders. So far it’s pretty lacking in that regards as the SDK is still very limited. I guess can’t blame them for focusing the 95% of the userbase.
You would have thought the hardware should be largely irrelevant though, as determining the need for acceleration should just be a case of how rapidly it is experiencing encoder inputs for a given variable.
I get acceleration of some sort when adjusting AP settings via the input knob on my Honeycomb Bravo, but I do my input management through spad.next so it’s sending the events over SimConnect. It’s using the regular PLUS and MINUS events, which should be the same as bindings done inside MSFS itself.
If I turn the knob somewhat slowly when set for “altitude”, it will go up in increments of 100. At some point, sometimes, it will suddenly switch to increments of 1000.
I have a hard time predicting when it will switch to increments of 1000, and often it does so when I don’t want or expect it, sending me a couple thousand feet over the target I’d intended. Further attempts to correct back to my intended target often engage the acceleration a second time.
Is this the same as what other people experience when using MSFS bindings on their Honeycomb Bravos or other input devices, or different?
I have both the alpha and bravo and flying GA aircraft I can confirm the problem. Increments for HDG and CRS are 1 deg per click of the rotating knob in the bravo. Its a total chore. Same for alt but with 100ft increment. No acceleratin with faster turning of the knob. I dont use any addon for key mappings.
In A32NX, even if you change the ALT to 1000, the knob assigned to altitude will still register it in 100 increments. I think same applies to if you GA aircrafts. No matter what, it’s an increment of 1 and 100. To me this patch they did screams a ■■■■ poor mask to cover the bigger problem that was caused by the constant on situation of an input.
Prior, the external rotary inputs worked GREAT with the only downside being to make sure that no input was in a constant on position (could be resolved by 3rd party software so switches acted as momentary instead of always on position) The acceleration worked wonderfully, you could switch between 100/1000 adjustments in altitudes, I mean it felt like a real input device. slow rotary turns = 1/10 increments and faster rotary turns = 10/1000, it just worked automatically and it was great! External rotary inputs were awesome to use and then they absolutely butchered it with the so called “fix”.
Unfortunately, we’re part of a niche userbase that is having these issues so it’s pretty low on the priority for a legitimate fix.
Using the Honeycomb Bravo the trim encoder is painfully slow to adjust due to this issue. It seems to only register up/down movements at a certain interval and have to be careful not to spin the dial too fast, there is no acceleration with continuous up/down input.
Using the other encoder dial for alt, hdg, vs etc works better as there is acceleration with continuous turning of the dial.
This acceleration is really needed for the trim control too and ideally the accel factor user controllable.
I found Workingtitle G1000 Nxi HDG has rotatory acceleration builtin, but, here is the but, CRS it does not have that. which means, encoder input acceleration can be built-in in the system, but need developer additional work