FFB cyclic trim issue, not holding the selected center

[Havner]

I have VPForce Rhino and the FFB in DCS in general is working fine, not an issue with setup. Flying Hip/Hind/KA50 without any issue.

The issue is with Apache. When I hold the trim everything is fine, the stick is light. When I release the trim the stick sets a new center, but not the one I had when releasing the trim, but one 20-40% closer to the center. Every single time. It's impossible to trim the heli. This doesn't happen in any other heli in DCS.

I can workaround this by implementing the force trim outside of DCS and then it works fine. But with the DCS FFB it's broken. Is it by design? Is there some Apache autopilot thing I'm not aware of? Or what is happening?

I've seen mentioned in other FFB related thread to spaw FFB axis, but as expected this completely broke the FFB (after releasing the trim the stick moves to the oposite side of the center).

[Hiob]

2 minutes ago, Havner said:

I have VPForce Rhino and the FFB in DCS in general is working fine, not an issue with setup. Flying Hip/Hind/KA50 without any issue.

The issue is with Apache. When I hold the trim everything is fine, the stick is light. When I release the trim the stick sets a new center, but not the one I had when releasing the trim, but one 20-40% closer to the center. Every single time. It's impossible to trim the heli. This doesn't happen in any other heli in DCS.

I can workaround this by implementing the force trim outside of DCS and then it works fine. But with the DCS FFB it's broken. Is it by design? Is there some Apache autopilot thing I'm not aware of? Or what is happening?

I've seen mentioned in other FFB related thread to spaw FFB axis, but as expected this completely broke the FFB (after releasing the trim the stick moves to the oposite side of the center).

No curves or saturation applied to the axis?

Have you tried the different trim options in the special options?

I haven’t used the Apache in a while so I can’t tell first hand right now.

[Havner]

10 minutes ago, Hiob said:

No curves or saturation applied to the axis?

I had saturation, just tried without it and it's fine now. But this is definitely a bug when using saturation + FFB.

10 minutes ago, Hiob said:

Have you tried the different trim options in the special options?

FFB should be used with instant trim.

 

EDIT: just checked, this is bugged on all helis... WOW.

Edited October 29, 2024 by Havner

[Havner]

I've reported this:

 

[MAXsenna]

34 minutes ago, Havner said:

I've reported this:

 

And I responded. You can't use curves or saturation with FFB sticks.

[Hiob]

46 minutes ago, Havner said:

I had saturation, just tried without it and it's fine now. But this is definitely a bug when using saturation + FFB.

FFB should be used with instant trim.

 

EDIT: just checked, this is bugged on all helis... WOW.

 

That‘s not a bug.

You are not supposed to use saturation or curves with FFB sticks.

[MAXsenna]

43 minutes ago, Havner said:

I had saturation, just tried without it and it's fine now. But this is definitely a bug when using saturation + FFB.

FFB should be used with instant trim.

 

EDIT: just checked, this is bugged on all helis... WOW.

 

It's not a bug. The FFB base doesn't know how to behave when you change length of stick virtually, (saturation).

[Havner]

3 hours ago, Hiob said:

That‘s not a bug.

You are not supposed to use saturation or curves with FFB sticks.

 

3 hours ago, MAXsenna said:

It's not a bug. The FFB base doesn't know how to behave when you change length of stick virtually, (saturation).

Sorry guys, but completely disagree with you. There is nothing that stops them to implement this. There is no technical, logical or any other showstopper to make it work. The FFB can "know" everything as FFB is driven by the game and the game knows the saturation.

The same as saturation changes the logical output of an axis it can change the logical "center" of the spring FFB effect as that center is sent by the game.

[MAXsenna]

Sorry guys, but completely disagree with you. There is nothing that stops them to implement this. There is no technical, logical or any other showstopper to make it work. The FFB can "know" everything as FFB is driven by the game and the game knows the saturation.
The same as saturation changes the logical output of an axis it can change the logical "center" of the spring FFB effect as that center is sent by the game.

Call it what you will. It's not a bug. DCS probably implemented FFB without the devs ever having a suitable device, so there's that.

Sent from my SM-A536B using Tapatalk

[Havner]

11 minutes ago, MAXsenna said:

Call it what you will. It's not a bug. DCS probably implemented FFB without the devs ever having a suitable device, so there's that.
 

About time they went back to the drawing board and expanded the implementation with more and more devices on the market now.

[MAXsenna]

5 minutes ago, Havner said:

About time they went back to the drawing board and expanded the implementation with more and more devices on the market now.

On that we agree. I still have to swap the axis in every module for some reason. "Same" with inverting brake pedals... 

[Number481]

I will agree and disagree with everyone in this thread 

*Saturation* (axis scaling) should not be hard to implement.  It's supported in the Rhino telemetry software for the "Civilian sims" where the entire FFB implementation is handled by the application.

*Curves* are a whole other animal.  This doesn't bother me though since I generally believe curves are bad.  Most people who are using curves should be using saturation/scaling instead.

 

The fundamental issue here though is that there is zero relationship in DCS between the axis x/y and the FFB x/y.  When you invert an axis, the "ffb stack" has no idea, so forces would be backwards until you also invert the "FFTune" for the same axis.  When you set up saturation on the axis, you've essentially made the full physical range of the axis only produce some % of the virtual range... but the "FFB stack" still thinks its %100 stop to stop

 

@Havner, I can show you a trick using the configurator software to produce a "saturation" of sorts.  In configurator, simply manually increase the calibrated range the same amount both on the upper and lower ends of the range.  For example, if your calibrated range was 1275 - 3000, you could manually increase the range by 200 on either side (1075 - 3200).  This would cause the full physical deflection to only account for roughly %80 virtual deflection.

*Edit*  I'll add that you can dynamically push profiles to the device based on the aircraft you load into (using TelemFFB), so you could do this on the Apache, but not for others if you wanted.

Edited October 30, 2024 by Number481

[Havner]

1 minute ago, Number481 said:

I will agree and disagree with everyone in this thread 

Well you basically agreed fully with me And I fully agree with everything you said.

1 minute ago, Number481 said:

*Saturation* (axis scaling) should not be hard to implement.  It's supported in the Rhino telemetry software for the "Civilian sims" where the entire FFB implementation is handled by the application.

Correct.

1 minute ago, Number481 said:

*Curves* are a whole other animal.  This doesn't bother me though since I generally believe curves are bad.  Most people who are using curves should be using saturation/scaling instead.

I never said anything about curves. Not using them and (would have to think this through) but probably might not be so easy to fix as the saturation is. But again, not using them, didn't report them, did not claim they are easy to fix or should be at all. With high end equipment and long sticks there shouldn't be a reason to use them anyway as you said.

3 minutes ago, Number481 said:

The fundamental issue here though is that there is zero relationship in DCS between the axis x/y and the FFB x/y.  When you invert an axis, the "ffb stack" has no idea, so forces would be backwards until you also invert the "FFTune" for the same axis.  When you set up saturation on the axis, you've essentially made the full physical range of the axis only produce some % of the virtual range... but the "FFB stack" still thinks its %100 stop to stop

Correct. The question is what a specific option is for. Because the "invert" might be to fix some discrepancy in the base that have X/Y mixed for output and FFB (akin to inverting wheel brakes axis in DCS). The saturation is not to fix discrepancies in the base. It's for the user (cause he prefers them for whatever reason) and the axis output and FFB output should match the settings, be consistent. It's not ATM.

5 minutes ago, Number481 said:

I can show you a trick using the configurator software to produce a "saturation" of sorts.  In configurator, simply manually increase the calibrated range the same amount both on the upper and lower ends of the range.  For example, if your calibrated range was 1275 - 3000, you could manually increase the range by 200 on either side (1075 - 3200).  This would cause the full physical deflection to only account for roughly %80 virtual deflection.

Thanks, but no need I'm fully aware of that. Also Rhino can implement its own force trim keeping all the other FFB effects from the game intact. I have no issues with workarounding this bug in at least 3 ways in total. The thing is that this behaviour should be fixed in game. I can workaround it, Moza users I presume might have bigger issues with that. And knowing FFB stuff from racing sims, different bases have different options. And none commercial bases have so many options as Rhino. So the issues should be fixed in game as people with more commercial bases might not have means to workaround it.

[Raven (Elysian Angel)]

On 10/29/2024 at 8:06 PM, Havner said:

It's impossible to trim the heli.

I have no idea if I use different settings but for me it works fine. Yes the Apache is very twitchy at the moment but trimming works well and as expected - on my end at least 

[MAXsenna]

I have no idea if I use different settings but for me it works fine. Yes the Apache is very twitchy at the moment but trimming works well and as expected - on my end at least 

He changed the saturation, that's why. DCS do not support this for FFB. Whether one thinks/claims it's a bug or not, it's been known for years. Literally one of the first things I found out when I got my stick back in the days.

Sent from my SM-A536B using Tapatalk

[Havner]

On 10/31/2024 at 7:21 PM, Raven (Elysian Angel) said:

I have no idea if I use different settings but for me it works fine.

Thanks, but I found the culprit, described it in further posts.

On 10/31/2024 at 7:21 PM, Raven (Elysian Angel) said:

Yes the Apache is very twitchy

Yeah, same feelings here (compared to equally heavy Hind or Hip), but that's a thing for another thread. I presume someone covered that already. I'm not following the forums.

[Schlomo1933]

If you need to setup deadzones, curves or saturation : do this directly in the software from the FFB Stick. Not in DCS ☝

[Picure]

I have the same problem but I dont have any saturation or deadzones in my settings. My stick does not sit still when I trim the helicopter. I havent flown DCS for over half a year and I didnt remember this happening before

 

[admiki]

Ha ha, got to you before you could amend your report like you did in other thread.

You have double binds.

Long time no see man.