Havner

Thank you for your posts. I don't follow the forums, but I had very similar opinions on the Apache since day one. I love "using" it. I hate flying it. And I love flying all the other choppers in DCS. I can't believe that such a heavy machine is so twitchy in the yaw. And even if for some reason it was inherent characteristic of its model I can't believe they wouldn't fix that with SAS. Right now it's actually a little (very little) easier to fly it with yaw SAS turned off. Which says a lot. Anyway, I don't have much problem with flying it like as we all I got used to it. But the behaviour of its flight model (comparing to equally heavy choppers like Hip and Hind) amazes me, how unbelievable it is and how unbelievably uncomfortable for the pilot it is. I really do hope that the announced flight model rework will come relatively soon and it will be good. I love this chopper, I want to love it fully. Right now unfortunately I hate flying it. Another things that is seriously missing is FFB. But it goes to all modules made by ED, so nothing special here. It basically only implements force trim and that's it. We have to use external software that generates some (unfortunately) static effects to have something more. And here goes another point you mentioned. Lack of cockpit shake. One of the effects I add to the FFB is ETL shake. Unfortunately it doesn't come from telemetry, you need to statically set between what speeds to add it. And when I was doing that for the Hip and Huey I had no issues to see those speeds as the cockpit was shaking like crazy. I couldn't see that in Apache at all. I feel the ETL changing the handling characteristics (obviously) but I have no idea when exactly does it start and when it ends. I'll have a look if maybe the sliders you guys mentioned is fixed now. Anyway, count me in to the list of people eagerly awaiting Apache flight model revision. EDIT: Nope, no effect whatsoever.

Thanks, but I found the culprit, described it in further posts. 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.

Well you basically agreed fully with me And I fully agree with everything you said. Correct. 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. 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. 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.

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

Sorry, you can call it what you wish. A missing feature, a bug, a known limitation. Something doesn't work as expected and can be fixed. Doesn't matter. There is no section on the forums to report "known limitations". For all intents and purposes here it's a bug. Also why would I care that you don't care? This is a bug report forum. This post was not meant for you, but for the devs. Also this post is not about what I can do with it. I can workaround it in Rhino software, but it doesn't make the bug any less of a bug. Moza users probably won't have an option to workaround it.

The FFB doesn't need to know that. The game needs to send a rescaled center for the FFB spring effect center. And the game has this is info as it has both, the saturation and the "virtual" force trim center. There is nothing that stop DCS to implement this. So if you have a saturation of 50%, the force trim center at: physical: (100, 100) logical: (50, 50) DCS now sends (50, 50) as the FFB center (hence the stick moves to the center). It needs to send a physical stick location (100, 100). Simple as that.

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.

I've reported this:

This is for helis, tested Apache, Hind and Hip, so I presume it's bugged across the board. 1. Use FFB stick 2. Set saturation on the pitch/roll axis, e.g Saturation Y to 66%. 3. Use force trim When releasing the trim button the stick moves away from the set position ~33% closer to the center that it was released with. Makes using FFB force trim impossible with some saturation set.

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.

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).

@MadKreator thanks for the answer. I guess you answered my question in a way, that there is no correct way to achieve what I want Doing what you suggest is a workaround. I might experiment with it. What I don't like about it though is that dimming the in game displays will compress the histogram which will then loose details when brightening them with reshade on exported displays. But like you said, nothing more that can be done here anyway. Regarding the Apache, what I meant is that that's the only module that actually has a proper solution done by ED (albeit by chance I presume). The in game displays have a brightness rotary that affects only the in-game displays, but not the exported ones. So I actually can dim the in-game displays completely (they are black) without affecting the exported ones at all.

Hi, Is there any way to hide MFDs or any other exported display when it is being exported? The issue is that there are brightness differences between exported displays and the ones in virtual cockpit. I already brighten the exported ones with Reshade + mask (as describe in a thread elsewhere) but the brightness difference can be significant at night that blinds me (I have OLED tv with high brightness). The ideal option would be to hide the exported displays, e.g. make them simply black. In Apache I can achieve that with the brightness rotary that affects virtual displays, but not exported ones. But it's only for Apache. Is there a generic way to do that? For A-10, or F-16. Screenshots to visualize the issue. Sorry for low quality, but my phone has broken stabilization.

Everything's perfect again. Much appreciated

Thank you for this very insightful and much needed knowledge. I don't know what we would have done without people like you.