2 hours ago, Tomaz Drnovsek said:

If FSUIPC and A2A were able to solve the issue in previous sims, Asobo should be more than able to do it in MSFS.

 

Sure they could, but why would they take so long is probably just for other reasons:

https://forums.flightsimulator.com/t/discussion-sim-update-3-1-14-5-0/375656/701?u=CptLucky8

Quote

 

Does it mean their interpretation of the 10deg bug problem was this bug in their code base and since they solved this bug in their code base, they thought they solved the 10 deg bug without actually knowing what it is we are talking about in these forums and therefore begging the question why we are loosing time reporting?

Or

Does it mean this is an unrelated bug they have corrected but the specific 10 deg acceleration bug correction is still not released and won’t be until WU4 or a hot fix in between?

I find this really really puzzling not in terms of not being able to correct bugs, but in terms of is there really someone able to comprehend the reports we send via Zendesk or via Topics with votes, able to understand what it is about, and able to translate this into technical explanation to a sufficient level so that developers can more effectively understand what it is all about.

I’m sorry to insist on this but I believe the 3rd party developers are able to cope with understanding the link between simmers feedback and simulator function, and this further strengthen to me the idea of the shared source approach I’m exposing for the next Q&A and which you can support in clicking the heart icon here:

Live Dev Q&A: Guided Question - #61 by CptLucky8 5

 

 

As for the general acceleration bug (not the specific trim problem):

https://forums.flightsimulator.com/t/heading-increment-bug-10-degree-instead-of-1-explained/290173/272

Quote

 

the main if not the only problem is FS2020 accelerating inputs regardless of the input source, and this is the same bug since FS9 (in 2004). In other words, it goes like this:

• FS2020 calls Windows API to get the current button states
• It detects some buttons were already pressed since X secs
• It sets a global “is_accelerated = 1” in the code
• Any further input is therefore using “Is_accelerated”

Instead of:

• FS2020 calls Windows API to get the current button states
• It detects some buttons were already pressed since X secs
• It sets a per-button “is_accelerated = 1” for those which are, and “is_accelerated = 0” for those which aren’t
• Any further same input is only accelerated if its own “is_accelerated” is set to 1

There is really nothing fancy there and this is basic input 101 in any game and program. This is exactly how the Garmin GTN and GNS bezel knobs are accelerated too in the Garmin code (I know because we intercept and control this as well in the GTN and GNS V2 for XPlane and Fltsim).

 

 

As for the trim, their Javascript code is implementing such acceleration but my quick attempts to disabling the acceleration there were not working. Like user Grinde81 is explaining, it must be rooted inside the exe instead. I didn't test either but the pattern he is describing reminds me of the typical acceleration pattern with the keyboard: press and hold it outputs 1 letter, after .5s is repeats. I wouldn't even be surprised there is a correlation with the keyboard acceleration settings in Windows and the acceleration speed in FS2020.

 

Just now, Bobsk8 said:

Like I said, I have about 600 hours real life flying, and that has been my experience. 

Good. On the other hand I often find myself in a situation where I need more than just one or two clicks up or down to trim the aircraft. Would it be so wrong if the trim in the sim would work the same as it does in the real aircraft? 

For me this started with the last update. Before that it didn't accelerate.

1 hour ago, Tomaz Drnovsek said:

So, if you hold it, it doesn't accelerates?

It does not.  In fact, I thought at first the assignment did not work because the wheel movement was almost imperceptible  (Cessna 152).  

My FSUIPC setting:

ButtonRepeat=20,10
1=RB,3,C65615,0     -{ELEV_TRIM_UP}-
2=RB,2,C65607,0     -{ELEV_TRIM_DN}-

EDIT:  You folks make me doubt. Maybe my "holds" are shorter than yours.  I will make another careful, timed, test and report.

Edited March 14, 20215 yr by jetlag

I confirm.  I have pressed continuously for over 10 seconds.  No acceleration at all. I have recorded a video but don't know how to attach it.

6 minutes ago, jetlag said:

I confirm.  I have pressed continuously for over 10 seconds.  No acceleration at all. I have recorded a video but don't know how to attach it.

It's ok, that's what I wanted to know. I guess it works through FSUIPC the same way it works in P3D. Good to know. Thank you!

I have trim up and down programmed to joystick buttons and find it a bit hit or miss.  It actually feels like sticky buttons, but I don't think it is.  I've found fast tapping the number pad "1" and "7" keys to give a slightly better response.

I'm not too sure about the acceleration vs. linear issue, but to me at least, desktop flight sims don't trim realistically because there's no feedback to the yoke/joystick as the aerodynamic forces on the control surface change. That's why I've become used to making only small tap-tap changes in trim. I need to make small trim changes and then observe the impact on the instruments before trimming further.

12 hours ago, jrw4 said:

I'm not too sure about the acceleration vs. linear issue, but to me at least, desktop flight sims don't trim realistically because there's no feedback to the yoke/joystick as the aerodynamic forces on the control surface change. That's why I've become used to making only small tap-tap changes in trim. I need to make small trim changes and then observe the impact on the instruments before trimming further.

Sure, I make small changes too most of the time but sometimes I need larger trim and hold it for two seconds or more and then the issues appear. I'm just saying, would it be that wrong if trim would work the same as in real life? We want realism, don't we? At least as close as possible.

On 3/13/2021 at 2:31 PM, badgenes said:

This was 'fixed' in the alpha at least once lol.  I had not noticed its return but then again I use a Gladiator MKII and even with it fixed I have a difficult time dialing in trim using a modifier and the hat :0.  It just isn't very natural and I have not found a better way to map trim to this quality but limited input device.

The unfathomable operation of trim in MSFS is THE most annoying aspect of this sim. I spend more time struggling with it than with anything else, regardless of AC type. I’m surprised more haven’t complained about it. Even if you find the setting you want, if you pay attention to something else for a moment and when you look up again you’re either climbing or diving. 

At one point last year, don't remember the update, but I this was fixed, at least for me.  Then maybe a couple updates ago, it started with the sensitive trimming again.  The fix was short lived, but i enjoyed being able to hold the trim on my yoke and it gradually trimmed.  Now if i hold it for longer than a second, it sends the nose flying up or down.  So annoying when trying to trim on final.  

Have you tried my setup (a few posts up)?   I will test on other a/c types shortly and report back

Anybody know how I can attach a video?  I prefer not to share my dropbox.

I don't have problem because I use a DX axis instead of DX up down buttons for elev. trim. Then you can very easily set the trim axis in Sensitivity boxes in MSFS. You can make it linear or whatever, even milder than linear. Using an axis (wheel) is so much easier. I would give up my rudder pedals before giving up my trim wheel.