cow_art

Great, thanks for clearing that up for me

Thanks for your reply. But I still don't see how this explains what we see in the video. A few questions: - are you absolutely sure SAS saturation is currently implemented in DCS ? - the white boxes are the range within which the SAS can currently move the controls, right? So if SAS saturation happens, why doesn't the white box change shape (or its position relative to the white diamond)? In other words: when the SAS authority range gets smaller I would expect the box to shrink. - In OP's video around 3:25 you see the helicopter is in a hover and the green indicator for the rudder is bumping on the right edge of the SAS box. It probably wants to got further right at that point but it can't because the authority box ends there. A few moments later, torque increases from 60% to 80%. Shouldn't the SAS try to counter that by going left on the rudder? The white box indicates that it in fact could go left (the white box looks like the SAS has a lot of authority to go to the left, it just can't go any further to the right). But it does not. That leads me to believe that something is fishy. Or I am severely misunderstanding something and would be grateful if you could clear up my confusion. Thanks!

In the controls indicator (Right Control + Return to activate)

Interesting, I noticed something similar yesterday. If SAS saturation is implemented as bradmick suggests, this could explain it. But I am not so sure if it is? If SAS saturation was implemented in DCS, I suspect the "SAS sleeve" (grey area in the controls indicator) would decrease/change over time? But this clearly is not happening in the controls indicator. Honestly this looks more like a bug to me. If you look at the SAS indicator for the rudder at the end of the video: The SAS desperately wants to push rudder all the way to the right, although I see no good reason for it to do so (and at this point the SAS has a lot of maneuvering room to the left within the indicated SAS sleeve). Even when the torque increases, the SAS does not try to correct the rudder to the left to counter the torque. It still insists on pushing the rudder all the way to the right. Perhaps this is bugged or still WIP?

I think you describe the situation where one needs this pretty well. One situation where I would find this useful is, if I have managed to establish a decent hover but keep drifting forwards a bit too much (have to repeatedly make corrections that fight the trim position by nudging the cyclic backwards). If I had a very precise stick I could just pull the stick back a tiny amount and press the trim button to correct this. But even with pretty extensive tuning of my CH Fighterstick's curve and deadzones I still find it pretty hard to make such tiny corrections reliably without overcorrecting (only really possible when I have my eyes glued to the control indicator). Simply having buttons that move the trimmed position a tiny amount would instantly get rid of this problem. I think that would allow players to have a better experience that requires much less tuning of joystick curves and deadzones (I get that this is probably a non-issue for users with better hardware... or way better motor skills than I have). And yes, the workaround mentioned above (move virtual stick with button presses, then trim, then reset virtual stick) also works in principle. But that's just a workaround; I currently use it and find it unreliable and needlessly complicated. A better solution would be to add a few more keybinds that give players direct fine-control over the trimmed position. Hence my post in the Wishlist section

Am I the only one who absolutely loathes the horrible horrible Shkval in the Ka-50? Don't get me wrong, the Shark absolutely is a cool helo. But the FLIR alone makes the Apache the instant winner for me. And George is just icing on the cake, really. Finally a modern attack helicopter where I can focus on piloting. Even if the Apache is slightly unfinished at this point (hold modes...) I am already super-happy with it and can't imagine I'll go back to the Shark any time soon.

That's a good idea, and in fact I have already tried that. But while the available keys are indeed similar, they unfortunately don't do exactly what I need. The currently available buttons move the virtual stick (white diamond icons in controls indicator). What I am asking for, are similar keybinds that move the trimmed position (red cross icons in controls indicator). Nevertheless, the available buttons can be used to make a "poor man's version" of what I am asking: Use key presses to move the white diamond a tiny amount, then immediately press the force trim release button to "store" the new trim position; finally move your physical stick a little (to reset the offset you introduced with the key presses). That works in principle but it's quite complicated, quirky and unreliable (if your physical stick moves even the tiniest bit while you do this, the white diamond immediately resets and you have to start over ==> with that technique I definitely couldn't keep the trim buttons on the stick). Dedicated buttons for this functionality would be highly preferable. And my guess is, they could be useful to a lot of people who have to live with lower-end input devices.

TL;DR In my understanding, there is no extra layer compared to the A10. I guess you can think about it like this: Selecting an acquistion source in the Apache has a very similar function as pressing "TMS Forward Long" in the A10C. OP, if you are familiar with the A10C like your initial post suggests, it might help to think in a little more detail about what "TMS Forward Long" does in the A10. I know a lot of A10 tutorials tell you something like "if you aim your TGP at a target and press TMS Forward Long, the target becomes your SPI". While that is technically true, it's only half the story. What actually happens (to the best of my knowledge), is that TMS Forward Long designates the current SOI (your TGP in that example) as the SPI Generator. What that means is: wherever the TGP is looking, that is your SPI --> if you slew the TGP around, your SPI changes immediately (no need to press TMS Fwd Long again). Why is that? Because you have not really designated a single point as SPI, you have rather told the A10, which sensor produces the SPI. In that sense pressing TMS Forward Long has exactly the same function as picking an Acquisition Source in the Apache. It just selects the "most important sensor", the one that is currently looking at the interesting stuff. If you want other sensors to also look at that interesting stuff, you now need to press the slave button. "China-hat Fwd long" does the same thing in the A10: it moves all sensors to the point at which the current SPI Generator is looking.

One thing I noticed yesterday is that I need more deadzone on my cyclic axes than I do on other modules. The Apache seems to be quite sensitive to small inputs. I have an older CH Fighterstick which often does not re-center perfectly, especially after small inputs like the ones you make when you try to fine-tune a hover. So in case you (like me) usually manage to get in a pretty good hover ( < 10 knots or so) but then struggle to keep it stable and reduce the drift to near zero, try increasing your deadzone. I now use a deadzone of 5 for both cyclic axes (which is more than double of what I usually use). Hovering has become a lot easier for me.

No sorry it seems I didn't express this clearly enough. Both conditions a.) and b.) are checked simultaneously and both can cancel the control lockout (whichever happens first cancels the lockout). The assumption is that you normally want to return the stick to center after trimming (because you want to avoid the jump you mentioned). At least I do in 95% of the cases. And I need only a fraction of a second to center the stick (exact amount of time could be configurable of course). In all these cases the central trimmer mode works perfectly fine and you get NO jump. The problem with central trimmer mode is, that if you fail to return the stick precisely to the center you are locked out of your controls (that tends to happen when things are hectic). To remedy that problem, condition b.) exists. It releases the lock after a certain amount of time, even if you didn't manage to return your controls precisely to the center. In this case you probably will get a jump, yes. But b.) is a contingency and a small jump definitely beats crashing because your controls don't react anymore. (Edit: if you manage to always return your controls to the center perfectly, you'll probably never notice condition b.) is there at all. But if you don't you'll be thankful for it )

Ah great, thanks! I wasn't sure if that's the case (I have gotten used to instant trim, I have not tried the central mode in any of my helo modules in a very long time). All the more reason for ED to update central trim mode then!

One thing they could do, is to simply add a timeout to the central trimmer mode: After trim release is pressed the physical stick is disabled until a.) the stick is returned to center or b.) a certain amount of time has passed (0.5 seconds or some configurable amount ) That way you get the smooth operation of central trimmer mode, but avoid being completely locked out of your controls when you fail to return the stick _precisely_ to the center for whatever reason.

Yes. Think of it like that: DCS creates a "virtual joystick" for helos. This virtual joystick is what actually controls the movement of the helicopter. You can see the position of the virtual stick when you look down in the Apache cockpit. You can also see its position when you turn on the controls indicator with RCTRL+Return (the white indicators are the position of the virtual stick). To calculate the position of this virtual stick, DCS adds two inputs together: One of them is the deflection of your physical stick. The other is an offset, which you control by releasing the force trim button. Let's call this offset the "trim position" (this offset is represented as the red crosses in the control indicator). In the beginning, the trim position is at the center --> red crosses are at coordinate (0,0). No offset is added to the position of your physical stick --> your physical stick and the virtual stick are in sync. Lets say you move your physical stick a bit to the left. The position of you physical stick is now (-10, 0). The trim position is unchanged, it is still (0,0). So the virtual stick is now being held in position (-10,0) + (0,0) = (-10,0). Everything looks normal, your physical stick is still in sync with the virtual stick. Now you press and release the force trim switch (without moving your physical stick). The coordinate of your physical stick remains the same: it's still (-10,0). But when you release the trim button, the trim position is updated. It now ALSO becomes (-10, 0). When DCS calculates the new position of the virtual stick it again adds these two coordinates together: (-10, 0) + (-10, 0) -> (-20, 0). The deflection on the virtual stick has now doubled.

Cant speak for the TM T Flight pedals, but I recently upgraded from CH Pro Pedals to VKB T-Rudders for a similar reason. The VKBs are definitely an improvement over the cheaper CH pedals. Very precise and they feel very nice for helicopter flying. Other helos work very well for me now. The Apache remains pretty hard to control in the yaw-axis though. What helps me a bit, is applying a curve to the axis (I currently use a custom curve which is equivalent to 70% Y-Saturation for the first 8 steps, then it cranks the sensitivity up to reach 100% on the final step). But even with that, I still find it hard to precisely control the Apache's yaw, especially in a hover. That said, I am not sure how much the flight model should be considered finished at this early stage. I suspect things might improve when the missing hold modes are added.

Agreed! A big thank you to the SMEs here on the forums for being so friendly, helpful and patient with us gamers!

Ok, so heading hold is already working in the DCS Apache and I am just too bad to actually get it to engage reliably. Thanks, back to practice then (A thought: it would be cool if we could see in the RCTRL+Return control indicator, what the Autopilot/Hold modes currently do and their "authority sleeve". Might clear up some of the confusion and help us learn).

Yes, absolutely worth it for SP. If you play as pilot you can think of the Apache as a very capable Ka-50 where you don't have to bother with the Shkval to shoot things. Instead you can focus on flying and positioning/tactics. Love it!

Hey ED, great work with the Apache, thank you so much for bringing one my all-time favorite helicopters to DCS in such amazing quality! A humble suggestion: Could you please consider adding directional trim buttons like in the Hind (digital buttons that move the trimmed position of the cyclic/rudders by a tiny amount)? I think that would be extremely helpful for people who have to live with non-optimal input devices. Disclaimer: I put this as cheat, because I fully understand that the real Apache doesn't have this function. I guess the real Apache cyclic/rudders are so precise that such a function is not needed on the real thing. But I imagine for the average gamer who has typical fixed wing gear (= a short spring-centered stick with limited precision) these functions will be very helpful, for example when fine-tuning trim to get within hover-hold conditions. Thanks!

It's a good suggestion and indeed I already tried that: Use key presses to move the white diamond a tiny amount then immediately press the force trim release button to "store" the new trim position. It works in principle but it's very quirky and unreliable (if your stick moves even the tiniest bit while you do this, the white diamond immediately resets and you have to start over ==> with that technique I definitely couldn't keep the trim buttons on the stick).

It is only accurate if you have very good controls or are happy with a compromise (such as putting huge curves on your cyclic/rudders). I am currently using a CH Fighterstick / Pedals (which have a pretty low resolution: 255 steps per axis). And I can tell you holding a precise hover in the Apache is not exactly easy with that. I am not new to DCS helicopters, I can hover other high-fidelity DCS helos all day (I can also hover the Apache but I currently find it quite challenging and think, a fine-grained directional trim would make getting into a perfectly trimmed hover position a LOT easier for me). Bottom line: It's great if some people don't need additional trim functions, but other people might. And it really is a pretty easy thing to add.

May I also add one more suggestion: add directional trim buttons for cyclic/rudder which adapt the trimmed position in very small increments (similar to the beep trim in the Mi-24) I know its not realistic for the Apache, but I am sure it would be a massive help for people who have to live with non-optimal controls.

yea, that's why I started reducing altitude first with the Mi-8. Can't get into VRS when you are going too fast

It's probably not proper technique, but what has helped me with landings back when I started playing the Mi-8 was the following mantra: "lose altitude first, speed second". In other words: if you intend to land, start a good way out from where you want to touch down. Lower your collective a bit, so you start sinking. Trim back on the cyclic a little to control your descent rate. Keep repeating that a few times until you are pretty close to the ground. At that point you'll be low, but probably still quite fast. Now start pulling back on the cyclic more (and re-trimming + adapting collective) to lose your speed without re-gaining altitude. With a bit of practice you'll end up "low and slow" near the position where you want to touch down. Now carefully drift the final distance to the position where you want to land. When you get very close, lower the collective a tiny bit more to lose the final few feet of altitude.

Are you sure your controls REALLY recenter completely when you release them? Perhaps you don't have them calibrated perfectly and they don't go precisely to the center point. (check in the control indicator and if they don't snap back to the exact center, then perhaps add a little bit of deadzone).

My guess is the Apache will get a lot easier to control once the remaining hold modes are implemented. Going fast already works well, but going slow feels a bit like driving the Ka-50 with all AP channels off. I mean, its definitely doable. But I find it quite challenging and I guess hovering the Apache without any hold modes is probably not how it's done in real life.