TZeer

I haven't flown the Apache for a while, and currently at work, so will have to wait a bit until I get the chance. But I'm very curious if they have been able to remove some of the bugs I reported back in August. According to Raptor9 all my observations had already been reported by the SME's.

https://www.helisimmer.com/articles/real-pilot-impressions-ah-64d-apache-dcs This is the viewpoint from a current Apache Instructor. He's been flying the real thing since 2005.

@Raptor9 thank you for quick reply. Quick question. I have 2 other bugs I think. Should I make a post with them, or have they already been reported by the SME team? 1: "Heading Hold sub-mode Page 207 in the manual Heading Hold assists the pilot in maintaining the magnetic heading reference. If the force trim release switch is pressed, Heading Hold is disengaged, and the FMC Yaw channel will only provide command augmentation and rate damping. When the pilot stops pressing the force trim release switch, the FMC will update the Heading Hold reference to the current magnetic heading." While pressing the force trim release, it seems the FMC does not give any command augmentation or dampening. The green indicator is glued to the white marker on the YAW channel. 2: While in Position Hold sub mode, moving the rudder pedals >3% does not disengage Heading Hold. Instead the FMC fights the pilot until you reach saturation before it starts turning. Easing up on the pedals again, turns the chopper back to it's original heading. Best regards

In the manual it says: "When a control input is made, the FMC detects the flight control movement in the respective LVDT axis (or axes) and will command movement of the SAS sleeve within the applicable flight control servo-actuator(s). This provides a “power steering” response to remove the lag effect of mechanical inputs into the flight control servo-actuators. At lower longitudinal airspeeds, the amount of CAS input is proportionally increased to ensure the aircraft handling remains consistent with flight at higher airspeeds." "CAS is disabled in the FMC Yaw channel when the aircraft is on the ground (determined by the weight-on-wheels or “squat” switch). This prevents oversteering during ground taxi." This is not happening while on the ground. If you put up the overlay for joystic and control behaviour, you can clearly see the CAS is working and adding YAW inputs when using the pedals while on the ground. This explains why so many feel the Apache is super twitchy while taxing on the ground. (That is if I understand the joystic overlay correct. I assume the green bar moving ahead of the white marker is what output the FMC is doing, and the white one is what the physical pedals/cyclic is doing?) See attached track. Best regards AH64D_YAW.trk

I would have if I flew in 2d But I fly in VR As of now, I only think this is an issue for us VR users chasing every millisecond in frametimes to increase performance in the Apache.

If you have capped your FPS @ 90 you will not see anything. As you have plenty of extra resources to spare. I tried to cap @ 90 FPS, but due to the FPS bug, where powerful cards as the 3080, 3090 and 6900XT get weird behaviour, my FPS dropped to 60-70 FPS. I need to have minimum FPS in the autoexec.cfg at minimum 190 FPS, if not, my FPS goes down to 60-70 FPS with my current settings. I tried using MSI afterburner to see if I could get some data from it. But nothing useful. Only thing I was able to see was as the FPS went down, my average frametime went from around 6 ms, to 7ms. And the framebuffer went down.... It might be something CPU bound. Since when I increased MSAA to 4x, I could no longer see the framedrop. This might also explain why it's more of an issue in VR than in 2d. As CPU time is much more imponrtant there.

Here is a screnshot of my settings and a small track. So I get a reduction every time I move my view left or right. Zooming out or in seems to make it go away. It's not much more than -20 FPS maybe. So 10% hit relative to my 200 FPS looking straight in the cockpit. Since I normally fly in VR I don't use MSAA, as it sucks to much performance. But I had a test where I added 4xMSAA while in 2d mode. Now I suddenly have an INCREASE of FPS when looking left or right. It's not much, maybe 10 FPS. I will do some testing in VR, and see If I get some usefull data from it. Edit: Was unable to get anything decent. Think my memory got maxed out. Was getting about 75 FPS average with a 99% utilization on my GPU and 14% headroom on my CPU. But suddenly my FPS went down to 60 FPS, while the GPU utilization went down to 70% and CPU headroom went up to 25%.... My videomemory was maxed out @ 16gb cockpit_fps_test.trk

This line is at maxfps=500. So that's not the issue. Doing the same thing in the Huey gives me close to 300 FPS. I had a post in a different part of the forums where this was the issue. And you came to the rescue with the solution . A while back ago I was able to get the Apache to run @45 FPS locked in Rivatuner with motion reprojection off in OpenXR, with a Reverb G2 @ 90Hz. The flight was buttersmooth. Cockpit was crystal clear, and no artefacts due to MR. Only had some ghosting on objects when looking to the sides. But the smooth framerates was well worth it. I went to work for 2 weeks, came back, updated DCS, and have never been able to get the same results again. Anyway. Problem here is that people who usually fly in 2d and run FPS locked at 60FPS or whatever. Or having G-sync monitors never notices if their FPS goes from 100 to 80 FPS. But when you are running VR, or are already on the limits of decent perfromance, this kinds of issues gets very obvious.

@BIGNEWY will do it later I know, awesome frames, and quite lucky. But as I mentioned, with lower tier cards and in VR, drops like this is the difference between a fluid gameplay and stutter. I normally fly in VR, and the performance drops when looking out to the sides are very noticable. This kinds of issues are also not always very easy to find. As they don't usually come to light until you have enough overhead performance available.

@BIGNEWY Ok, so did just a quick test in 2d mode, as it's visible there as well. I did the test in Nevada, in the very west lower part, where there is not much going on. This to keep terrain details to a minimum. Anyway, this is visible on all maps. Fist picture is inside the cockpit. Doing above 200 FPS, looking straight ahead. Next pictures are to the 90 degrees left and right in the cockpit. When taking the pictures they drop to 130 FPS, but while in flight the reduction was roughly 20 FPS, 180 FPS. But for some reason the massive FPS drop while taking a screenshot, only happens when looking to the sides. Not towards front. There the FPS keeps at 200+ FPS. This is on a overclocked AMD 6900XT card, and we can argue that the FPS drop is a non issue since we are still running 180 FPS. But when we are getting into lower tier cards and VR space, this drop gets very noticable. Putting up the video feed from the TADS, my FPS dropped to 150 FPS, now I had no difference when looking to the sides. And I got same behavior when taking screenshots. All 3 instances dropped the FPS to roughly 95-100 FPS. Question is, what is making the FPS drop when looking out of the cockpit to the sides?

I have seen the same behaviour in Caucasus and Nevada. Smooth as butter looking straight ahead (Motion Reprojection activated), turning my head to left or right, and gradually the stutter gets more and more visible. I will see if I get some time today to make a post with performance metrics etc from the GPU/CPU-load, combined with the observed behaviour. I seem to remember that when this happened I also observed changes in the GPU/CPU workload.

You can still get this in normal flight. If you trim you aircraft (Force Trim Release), and operate the Apache in a way that makes the SCAS reach it's limits, you will saturate the SCAS. Let's say you trim your Apache to fly straight. Let's say you are doing 90 knots. The SCAS is then trimmed at that spot and will assist you. Yaws, stick etc. Now you want to decrease speed. As you loose speed, you will need to increase input on your Yaw. If you don't, the SCAS will do it for you, until the 10% limit is reached, and it's saturated. To avoid this you can do 2 things: 1: Hold down the force trim release, until you are happy with your new inputs. Yaw, stick etc. 2: Keep tapping the force trim release as you work the pedals to give the SCAS a new center point to work from as you increase torque. Just remember to recenter the pedals between each tap, if you are using spring centered pedals with matching settings.

Back from work now, so had a quick test on the Position Hold in combination with giving yaw inputs to change heading. As @Raptor9 mentioned earlier, the SCAS is fighting every input I do on my pedals, until the SCAS get saturated and "gives up" and finally starts turning the chopper. When trying to turn the other way again, it's extremely sensitive, but doable, as long as you are handling the pedals as it's the finest crystal. It does not seem like the SCAS likes what I'm trying to do, as it really starts "acting" up, and struggles to keep Position Hold active.

Just tested. Could not get altitude HOLD to engage in any way. No sound, no message in EUFD and no box in my IHADSS. Tried engaging while in flight below 100 FT. Tried engaging while in hover. No joy.

So just to build upon what you are saying here, with my setup ( no spring setup ). Regardless of my HOLD modes, I should see yaw movement while in hover ( manually or ATT Hold ) if I push my pedals more than 3% of the trimposition? Now again, the yaw seems quite aggressive sometimes ( I don't have any curves ). Could this be the reason I feel it kinda "snaps" at me when getting over the 3%?? Seems that when you get past the 3% threshold, the simulator suddenly adds the 3% on the yaw input, instead of just taking the input from where the 3% get's crossed. Example: Stable = 0% of trim position 0-3% = Nothing happens Passing 3% = Suddenly adds 3% input to yaw (With the sensitivity of the yaw as it is now, this makes the Apache kick out it's tail more aggressively than you wanted) 6% = 6% yaw I'm at work right now, so have no chance of testing it now.

Appreciate your feedback @kgillers3. I have a VIRPIL ACE pedal, where I have taken off the spring and installed a damper mod. I have also reduced my deadzone, as I do not need to re-center between trim. Has greatly increased the feeling and ability on the rudders. I am thinking that maybe the best solution for me, as of now, is to disengage ATT Hold, turn to new heading, and engage ATT Hold again. PS: For anyone looking to do this mod. It's very easy. And no need to move the spacer to the underside as done in the clip. After assembling all parts it took about 10 minutes to install. Like this one:

But it's still a sort of a workaround to get it done. First one is forcing the apache outside the SCAS authority. And only works on large movements. Second one is "tossing" it in the direction you need and retrim before it goes back. Making the whole thing oscillate until it stabilize in the new direction. Look at this footage of how stable the whole thing is while hovering above ground, and doing two 90 degree turns. There is no sign of any oscillation or anything. But I guess it's a little different, since it's probably not in any hover hold modes. I could probably try disengaging attitude hold, before applying inputs on the rudders. But will be a challenge if the SCAS has some inputs that needs to be compensated when taking off the attitude hold mode. Any tips from @Raptor9 or @kgillers3 maybe? What is the correct way for the Apache Pilot to correct heading while in hover? Do you just push and hold FTR while doing it? Or disengage the hold modes while turning? Hopefully it will be refined as the FM still is WIP.

Note: I have a springless setup with a damper-mod installed on my VIRPIL pedals. So no re-center of pedals between trim. I have the same issue with aligning the aircraft while in hover. I can get into hover quite easily, stable and fine. But when I want to change my direction to get a better firing solution for targets out to either side, it seems the SCAS keeps fighting me. Pushing the FTR just knocks the aircraft into some unstable mode, and you really have to fight to keep it stable. And this happens regardless of how stable you are before you engage hold modes. I can get it 99%. Small drift but showing 0 knots, stable altitude etc. Stable hover --> Engage hover --> Engage targets --> Turn left/Right??? How?? What is the correct way to align the chopper left/right a few degrees to improve firing solutions for targets out to the sides?? No matter how I do it, I feel the SCAS is fighting me. And pushing the FTR just makes the whole thing unstable....

With added meltdown of VR performance.....

Think you are are talking about 2 different things. First one is when George is slewing onto a target. One can see the crosshair might not be 100% on target, but slightly off, then for a few seconds the crosshair creeps closer to center of target. And you have positive lock. I guess this is to simulate a human doing the final adjustment to be on point before lasing and firing. Second one is when George loose sight of target.

Only had 1 type loaded. One of the first things I checked when I saw the "Weapon ?" message on my IHADSS.

@Zboboinator I did, WAS (Weapon Action Switch) to rockets. Change to guns and back to rockets again did not fix it. But I could fire the cannon without problem. @admiki I will have to do it some other day then. I left for some work today, so will be away from computer for a few days.

I'm just cheking here to see if I'm having a "brainfart". Weapons Armed (yellow) WAS rockets (only have 1 type loaded) Tell George to lock up target with rockets activated. COOP indicating in IHADSS. Align to target, solid marker, everything looks good. Press fire.... nothing happens. IHADSS shows "WEAPON ?" as I pull trigger. Change CPG to free weapons, he fires as normal. Switch back to COOP, no go. Change to guns, fires as normal. Sooo, what am I missing fellow rotorheads?

@Flappie Ok. Was just curious. Cause if you where close to max gpu usage @ 180fps. You will not see this behaviour. If you have MSI afterburner installed, you can use it to log your GPU usage in the background. One last thing you could check. You don't have a startup file overriding your graphics.lua settings? If you have stable 180 fps, without maxing you GPU and CPU, and max fps in graphics.lua set at 300. You have some other issue holding you back. @Hiob I found one of the topics where you assisted another guy with the same issue. 4k resolution, max 50 FPS etc. He was using a 3080Ti, so it's not just AMD but all GPU's of higher performance level. This should really be fixed by ED in an update. Imagine how many people out there are running 3070, 3080, RX6800 or better GPU's and getting performance way below what their systems are capable of. It's a quick and easy fix.