Huey force trim implementation doesn't match the manual (or reality)

[Rangoon]

On page 43 of the DCS Huey manual, it correctly describes the behavior of the force trim button, being that it reduces the force to zero while "pressing and holding the force trim push-button switch on the cyclic..."

 

At least in the UH-1 Victor model which is the UH-1H outfitted for HEMS, that is the behavior of the button, plus the fact that when you release the button the force trim actuators are re-centered to that new position. So you press, hold, release. The hold zeroes out the force while depressed, and the release sets the new position. In this sense, it's very much like the DCS implemenation of the Ka-50 trimmer.

 

I'm just curious why the same wasn't done for the Huey? It's easy enough to assign the HOTAS command to activate on *release* of the button, rather than on the *press*, but if one were to use a FFB stick then you would also presumably want to feel the forces zero out while holding it. And if the manual states is correctly, and the Ka-50 is implemented (presumably) correctly, why not the DCS Huey?

 

I know, it's a small thing. But someone took the time to write that statement into the manual, and it reflects reality. To me, it also feels better to hold the button while everything gets dialed in, and the release to set, rather than hovering over the button, dialing in, then pressing to set. And any decent HOTAS software can accomplish this as a work-around, but why not code it this way from the beginning?

[KLR Rico]

Did it change? I haven't flown it in a couple weeks, but for me the force trim has always worked as you describe it should; there are no centering forces with the button held. I'll go fly it later tonight and see what's up.

[Flagrum]

I'm just curious why the same wasn't done for the Huey?

Well, but it is - and always was. At least for me ...?

[Rangoon]

Not sure if it changed. Maybe mine is not working correctly? My force trim engages immediately upon button press, not on button release. Ka-50 works on button release for me.

[KLR Rico]

It goes like this for you?

 

- Centering force set at initial point

- Push force trim button

- All centering forces go away

- Release button

- Centering force centered on the position the stick was at when the button was released.

 

That's the way it works for me, and always has. The shark is the same way.

[NeilWillis]

Have you tried it with and without the central trimmer mode option selected in special options?

[Flagrum]

Not sure if it changed. Maybe mine is not working correctly? My force trim engages immediately upon button press, not on button release. Ka-50 works on button release for me.

No idea if or how that could even happen, but perhaps your control mappings are screwed. I don't mean some sort of mapping conflicts, but in the definition of the mapping (i.e. what actions are mappable to "button down", "button up", etc.).

 

You might try this:

- delete ...\Saved Games\DCS\Config\Input\UH-1H folder (make backup first!)

- start DCS, map your controls again

- try it

[Rangoon]

Thanks for the ideas. I will try them this afternoon.

[msalama]

I last flew the Huey 2 days ago. I'm running the latest OB and there was no difference in how the trimming mechanism behaved, or at least nothing that I noticed.

[Rangoon]

EDIT/delete

Edited March 22, 2015 by Rangoon

[Rangoon]

My previous post was incorrect. It still is not working correctly for me. I thought I had tried it with just the keyboard command, not HOTAS, but either didn't or didn't notice it wasn't working correctly. I tried with my HOTAS, which I had forgotten that this morning before I left for work I had adjusted it to be *on release* rather than press. So it was a work-around I was seeing, not the proper DCS implementation. I tried again with the keyboard ("t") as well as HOTAS on press, both yielding the same behavior.

 

It goes like this for you?

 

- Centering force set at initial point

- Push force trim button

- All centering forces go away

- Release button

- Centering force centered on the position the stick was at when the button was released.

 

That's the way it works for me, and always has. The shark is the same way.

 

No, not for me. Here is how it goes for me:

 

- Centering force set at initial point

- push force trim button

- the cyclic position gets paused for 0.5 seconds while the trim is updated

- cyclic force trim is updated and added to actual control/HOTAS input

- release button

- nothing changes on button release (all changes/updates/effects take place on button press immediately)

 

So this is distinctly different from how yours is behaving. I want what you have!! :)

 

Have you tried it with and without the central trimmer mode option selected in special options?

 

Good idea, and indeed I have. The behavior is the same except for what happens at the cyclic pause stage (on button press, not button release). With central trimmer mode on, the whole things freezes there until the cyclic is centered (as to be expected, and like with Ka-50). Without, there is a 0.5 second pause (like with Ka-50) and then immediately combines the HOTAS input with the offset force-trim position (like with Ka-50). The problem of course being that this should all take place on release of the "t" key or the trimmer button, not on press.

 

No idea if or how that could even happen, but perhaps your control mappings are screwed. I don't mean some sort of mapping conflicts, but in the definition of the mapping (i.e. what actions are mappable to "button down", "button up", etc.).

 

You might try this:

- delete ...\Saved Games\DCS\Config\Input\UH-1H folder (make backup first!)

- start DCS, map your controls again

- try it

 

Good idea. I tried this, but no change.

 

I last flew the Huey 2 days ago. I'm running the latest OB and there was no difference in how the trimming mechanism behaved, or at least nothing that I noticed.

 

I also have the latest update (from a couple days ago).

 

Why is my particular Huey behaving differently from all of yours? Is this some kind of practical joke from ED? Hahahahaha very funny!!! :megalol: Now please let me have the normal Huey back :) :joystick:

[Rangoon]

It goes like this for you?

 

- Centering force set at initial point

- Push force trim button

- All centering forces go away

- Release button

- Centering force centered on the position the stick was at when the button was released.

 

That's the way it works for me, and always has. The shark is the same way.

 

So, to be clear, your Huey trimmer works the same was as your Ka-50 trimmer? And I assume this is without central trimmer mode on? I have tried both aircraft with and without central trimmer mode on, and have confirmed that the behavior is not related to that mode being on or not, but rather with the sequence of events.

 

When I press the trimmer key (t) or HOTAS button (keypress call of t), the trimmer acts as though it's looking for the pilot to recenter controls (the cyclic position diamond hangs for 0.5 seconds, or if central trimmer mode is on it locks the inputs until you are centered). If I *do* recenter at that point, and release the trimmer, the force trim does correctly record the release position, not the press position (of course the idea is most often not to force trim to center, so that behavior already doesn't make sense). Now it *is* correctly recording the position of the cyclic upon release of the trimmer button, however it has already moved past it's 0.5-second pause time, so upon release, anywhere other than center, the input is then doubled in both axes, so immediately jumps. The 3D cockpit cyclic jumps, as does the diamond. It's only correct then once you move the HOTAS cyclic to center, which cannot happen instantaneously, hence the Ka-50 behavior in DCS of the 0.5s delay or central trimmer mode. Is that how your Huey behaves?

 

I would expect, and it should logically be (right?) that the button is pressed, the contols are positioned, and the button is released. Upon release, the position is recorded as the new "center/neutral" and then you have the 0.5 seconds to return to center (or the with central trimmer mode on it locks the control inputs as they were until you do return to center).

 

In the real UH-1H, the button is depressed, the forces acting on the cyclic are relaxed, wherever the cyclic happens to be at button release is where the force trim tries to keep the cyclic.

 

So in the DCS Huey, it should be:

 

press trimmer

move cyclic

release trimmer

return HOTAS cyclic to center

sim cyclic is not offset by that trim position from center, while the HOTAS cyclic is in neutral

HOTAS cyclic input from neutral is now added to the sim cyclic (after the 0.5s delay or neutral HOTAS cyclic)

 

The point about relaxing the force trim pressure while the button is pressed is only hypothetical unless you're using a FFB stick, which I am not. Once trimmed, you move the (non-FFB) HOTAS cyclic just as freely as before, but now it's adding input to the sim cyclic's trimmed position, so pressing the button doesn't release any forces because they are undetectable in this sim/scenario without FFB. And as you'd expect, the cyclic diamond doesn't move when the button is pressed. It does, however, hang for 0.5 seconds waiting for a centering of the HOTAS cyclic, which it shouldn't. It should do that *after* the button is released.

 

Right?

 

And this is what yours is doing?

 

I have tried deleting the UH-1H input bindings folder, I have set, unset, reset, unset, and reset again all of the autopilot and trim related options for the Huey. What mine is doing defies logic, defies the manual, defies reality, and seemingly defies other users' experiences.

[msalama]

OK, just re-checked and my verdict's still the same: no change whatsoever. Is your central position trimmer mode off or on? EDIT: sorry, you've checked that already, didn't notice.

[Rangoon]

This couldn't have anything to do with the installation method, could it? I upgraded from BS1 (digital download) to BS2 (through DCS interface I believe). But I'm on the very latest version overall (updated again last night, in fact, I believe - small glimmer of hope - but same deal).

[msalama]

This couldn't have anything to do with the installation method, could it?

Can't imagine it could, unless something _really_ went massively wrong with the upgrade. But had that happened, I'm pretty certain this wouldn't be the only thing acting up.

 

So I'm stumped. No clue as to what may have caused that. Sorry :confused: