cow_art

Related to OP's point 1.) How well does it fly? This early access release is a bit puzzling to me. From a system modeling perspective the Apache feels pretty far along. But from a flight perspective it is somewhat of a mixed bag. The raw flight model might be pretty much finished. I can't really say as I am not a real pilot, but the raw Apache feels pretty much like other raw helicopters feel in DCS. (A bit more twitchy than I expected, but I can totally belief that's authentic). What currently seems to be heavily WIP is the Stability and Control Augmentation System (SCAS). If nothing else, there are definitely some hold modes missing, which makes slow flight and hovering more challenging than it probably should be. I also have had situations where the SCAS did wonky things I can not explain (I know that SCAS saturation is modeled and that might certainly contribute to my confusion, but I doubt that this is responsible for ALL the weird behaviours I have seen so far). I personally expect there are still some bugs and inaccuracies in the SCAS implementation (But I think its generally accepted that this part is still WIP, so writing vague bug reports is probably a waste of time at this stage). Bottom line: from a pure helicopter flight perspective my guess would be that its not finished or close to the "fully real" experience yet. That said, in its current state the Apache is already pretty cool and I'd definitely buy it again. It just might be a good idea to adjust your expectations and don't expect a finished flight experience yet.

Does anybody know if the Apache's behaviour during SCAS desaturation is already realistically modelled in DCS? For me the helicopter currently becomes very unstable while I hold force trim release. As a result I find it quite hard to perform this procedure without wobbling about like it's my first time in a DCS helo. I think that currently happens because of two reasons: - the SCAS does not produce any more stabilizing inputs at all (is that realistic? it sure might be, just curious) - the SCAS offset (green marker) is zeroed over a period of a few seconds. That leads to a completely new effective trimmed position and requires me to manually (and gradually) add the control inputs that the SCAS desaturation is removing. Unless I have the Controls Indicator turned on, I see no way to predict how one is supposed to counteract these changes. So is anyone in the know how this is done in reality? Or are Apache pilots just that good that it's not an issue for them?

Interesting idea! The rockets sure can be used in a lot of different ways. I currently find it easiest to treat them similar to the gun. Everybody agrees the Apache's gun is awesome and easy to use, right? I like to think of the rockets as a gun that can only fire straight forward (but can adjust up/down). So my current method for aiming rockets is as follows 1. fly straight towards the target (either line the target up with the diamond on the HUD or use the white line you discovered, whichever one finds easier) 2. periodically look at the target (place LOS reticule on target) 3. if target is in range (I-beam becomes solid) FIRE. If not in range, wait a bit then GOTO 2. That way I don't have to keep my head still for a long time. I just need to keep flying straight towards the target, periodically look at the target and decide if I want to take the shot. I tend to mostly ignore the I-Beam, but in that final phase it can be very useful to see if a.) you are in range and b.) you are lined up correctly

That makes a lot of sense, thank you! So how do you deal with this in reality? Are you waiting for the "SAS SATURATED" message to pop up, and then recenter the SAS sleeve when it happens? Or do you do it periodically so you don't have the SAS Saturated message pop up at an inconvenient time?

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.