Scaley

The yaw SAS channel (from my POV anyway) is broken and has been since launch. It AMPLIFIES every movement you make, and takes quite a long time before it slowly trends back to functioning as a damping effect. I've got the same pedals and with 80% saturation applied the amount of real pedal movement I use when taxying is about +/- 5mm at most. I actually tried to video the pedal movements for a youtube video but they were impossible to actually see in the video. You aren't alone. The best thing to do to learn is just desaturate the pedal axis to 60-80%. Some people also find a curve helpful.

OK, so having watched you video on 0.25 speed several times here's my thoughts (and much easier to understand since you had the control indicator showing): That wasn't anything I'd describe as "smooth long turns". The preceding few banks were pretty aggressive. 130kts at 15' is a very low/fast combination, and leaves you zero error margin. For NOE flight aim for 25' at 70-100kts at least to start with. The terminal manoeuvre begins as a roll-out of a right bank to level flight. You do this with quite aggressive left cyclic, with some forward cyclic blending in as you reach zero bank angle, and some left pedal. As you pass zero bank angle you try to stop the (now quite rapid) right roll with right cyclic, but also apply full (as in as far as it will go) forward cyclic. This essentially completely unloads the rotor disk. The DCS helicopter flight model REALLY does not like no load on the disk, and treats this as causing reduced control response. At this stage you still have a small amount of left pedal in. At the 15second point as you pass about 80deg of left bank you aggressively apply full right pedal. Since the Apache tail rotor is above the centreline of aircraft it will roll the aircraft in the opposite direction to the applied pedal, so in this case the right pedal increases your left roll rate. Essentially you now have the tail rotor (which is still effective) rolling the aircraft left, and the cyclic (which due to low disk load is not effective) rolling the aircraft right. The tail rotor wins, although even if you had not applied the right pedal I don't think that would have been recoverable with the amount of forward cyclic you had applied. Summary factors as I see them: 1) Manoeuvring too aggressively at too high an airspeed with too little altitude 2) Unintentional / instinctive forward cyclic application without understanding what this will do to disk loading 3) Unintentional / instinctive right pedal application to try to keep the nose up without understanding what this will do to roll 2 and 3 look like fast-jet reflexes that are probably conditioned in from flying things without rotors. Hope that helps! Edit: This is not retreating blade stall at 40% torque and 130KTAS. Even with the current DCS flight model you can get a sustained 150kts dive out of the aircraft at lowish collective.

DCS has intermittent problems with only recognising key and button commands when the button is held down for more than 50 milliseconds. This generally does not affect the settings page, only in the aircraft. I have never used expertkeys but see if you can find a way to send discrete "key press down" and "key release" actions instead of just a "send key" function. That might help.

Having the same issue but always inconsistently and intermittently, which means it's always part of a massive long track file. From observation it appears to occur more/worse on higher load servers in proximity to other aircraft or activity, and very very rarely on servers with good ping and low activity.

The TSD and PERF page will show "CALM" below a certain windspeed value which, from memory, should be 5kts.

Yes, PERF page was correct before, and TSD was wrong. So indeed the bug has just moved from one to the other.

All the controls in the present build work correctly as previously, and as per the manual. As Raptor has said, there aren't any controls missing. Everything you need is on the TDU. Depending on what sight and/or sensor you have selected they will control various things. It is all described in the manual.

Yep, there is a masking function so you can have certain reshade layers (or all of them) only affect a portion of the rendered output. See here for a good write up of how to do it:

Yep, you do. I think there is some misunderstanding that the boresight should be at the neutral head position. It's just an arbitrary point in space where all the circles line up. The fact that your round were impacting in the wrong place is a separate issue. I know the VR boresight procedure sometimes need to be different to the 2D one depending on your eye settings. There is a post in this thread explaining.

Interestingly every single Apache crew on the Rotorheads server has just been complaining about this, to the extent that one crew just gave up and went back to flying the Hind.

Having a chart scale that you didn't have to re-select every time you zoomed would be a good start!

Sort of. It's the "Attitide Hold" function mentioned above. If you activate it at 5KTAS or below if functions as position hold, so it tried to hold the position it had at activation. It's only been added in the last patch so is still a bit WIP. It also only has 10% control authority, meaning it only has 10% of the full range of cyclic movements available to it FROM THE TRIMMED POSITION (which is important) To use it you need to get to a stable hover and trim for that hover, then activate it. If you do that it's actually very good and you can definitely sit hands off almost indefinitely even in strong winds. NOTE: It has no control of collective - that's up to you Altitude hold, which is a separate function, is coming later. Once we have both then you combine them to get a proper hover hold.

Rotorheads and Low Level Hell

It might be worth you posting a video (ideally with the control indicator showing) of this. I haven't seen any problems in levelling out from steep turns either myself or when training other people (I had about 10 different people in the back seat so far for training). Let us know a bit more detail and maybe someone can help.

I've not seen anyone else report this problem. Some more details might let people help you work out why this is happening for you.

It is implemented and it works. It will not work in MP for the pilot who does not have the controls (it will show like it is on the MPDs, but not actually move). Check in single player while sitting on the ground. Having said that, generally the fix for needing to hold the cyclic forward is to trim, not use the stabilator.

The Apache yaw characteristics right now are very much a work in progress. The stability augmentation is doing some funny things that are probably amplifying the pedal inputs. The best technique to learn the characteristics right now is to set the Y saturation of the pedal axis down to 70% or maybe even lower. Obviously you will loose some range of travel, but with the force-trim system as implemented in DCS that doesn't really matter. Also make sure (as others have mentioned) that you don't accidentally have another control device bound to the pedals, and that you are using an appropriate force-trim mode on the settings.

Are both of these happening in VR?

George won't automatically pick a new target after the first is destroyed if that's what you mean.

This is where people are misunderstanding and making it seem worse than it is. You only need your head to be lined up with the circles at the moment you press the boresight button. It's setting a boresight, not a centre position. You are telling the aircraft "this helmet position matches to this known reference location and line of sight" for the system to use as a baseline for calculating from. After that you move your head however you want. You can use TIR, VR, key binds, or any other means of moving your virtual head and view in DCS and the system should know where your head is, where you are looking, and therefore where to point the gun.

Very much agreed. Current solution seems to be write an external macro/script to scrub the database when you load in, which is very annoying!

You'll notice as you look around the symbology doesn't change in COOP. The LOS cross represents the aircraft which you need to move over the I-BEAM. Where you look is now irrelevant. If you look 90° left the distance between the IBEAM and the LOS won't change since all it is now telling you is how much to turn the aircraft to achieve a solution. It's totally uncoupled from you actual line of sight, helmet position and the real world you see with your eyes. It now purely a "turn left or right" indicator, but it just happens to be displayed on the HDU. For all it matters it could be on an MPD with a black background. Hope that helps.

Always scanning, yes, like a human. Always scanning using exactly the current logic where he has infinite vision and detects everything, No. I didn't clarify that since it seemed to follow from the discussion.

You can't really "turn off" the trim completely in the Apache in any axis, because the whole stability system uses the trimmed position to determine (to some extent) what it's doing. If you have the pedal trim set to PEDALS WITHOUT SPRINGS AND FFB you will still see the red x that shows the trimmed position move. What will not happen is the physical centre position of your pedals will not be re-mapped to the trimmed position. What WILL continue to happen is the stability systems will attempt to hold the heading you were on when you release the trim switch, and the SAS authority limits will be centre on that trimmed point on the yaw axis (assuming you held the trim button down long enough). Other than completely switching off the stability system in the yaw channel (which you can do via the MPDs) you can't get rid of that, nor should you want to.

We might need a little more info to help you. What mission? Can you post a track, miz file, or screen recording. Did anything else happen at the same time?