Tepnox

I would like to contribute my findings as well. While I am as pilot in clear sight of the target, the FCR does not detect the target - the target gets detected by the FCR when the TADS has visual sight. In that case the whole Apache is now visible by the enemy and this should not be the work case scenario of the FCR it suppose. Changing manual elevation modes does not help either. Tested on Syria map. FCR-Issue.trk

I am also having some difficulties with proper FCR target acquisition. I checked also manual antenna elevation settings but it seems like the FCR is kind of useless in low altitude. Kind of disappointing because I was hoping it would now be possible to scan for targets while behind cover / tree-cover. It seems to me that minimal terrain or bushes / trees in direct line of sight of the FCR are blocking those big metal chunky targets magically away. I tested this on Syria map and will conduct some more testing on other maps soon. In one test scenario, I could only track 2 out of 8 targets (4-5 km away, 4x BTR-80, 4x T80) in low altitude behind a tree line. While climbing to 300 ft AGL the FCR slightly improved finding 5 out of 8 targets in plain sight with no terrain masking whatsoever. I find this very strange. If you have to be in 2-4km range like in Wags videos, the FCR seems kind of pointless because with that range you will get already shot by MBT or IFV.

I really liked the humor in the patch notes too. I think ED is slowly understanding how painful handling George can be from time to time. He can be glad the Apache does not have ejection seats like the Blackshark does. I surely would have forcefully ejected him several times by now - all WIP declarations aside...

It depends on the menu settings (cockpit resolution with every frame eats the most) and it depends alot of the rendered scenery in the TADS / PNVS. A hard case scenario is for my testing Beirut on Syria map. When having cockpit resolution to 1024 every frame, the impact for the TADS as pilot while viewing Beirut from the airport can lead up to 20 % more gpu utilization. If you add the PNVS also, you have another up to 20 % more gpu utilization. Switching scenery to more nature landscapes (less cities) can lower this impact to 10-15 % for each separate window (TADS / PNVS). When you switch to 1024 cockpit resolution (not every frame), the impact in Beirut is 10-12 % more gpu utilization per window. Going to nature scenery will lower this to 7-10% per window. Quite better tolerable. So this means, in worst case scenarios around Beirut with TADS and PNVS and 1024 res. every frame enabled you would need 40 % additional gpu utilization headroom for reaching your desired target framerate - that is quite unrealistic (maybe with the upcoming RTX 5090 series in 2025 we have this headroom). So right now we have to live with stuttering in VR in certain circumstances using the TADS / PNVS. In short, yea the TADS and PNVS eats FPS like hell (but nothing unexpected). I trimmed my VR settings to get full 80 fps (no ASW) with the TADS enabled in nature sceneries. I will get below that target while watching cities. In night operations it does not bother me to fall below 80 fps (I have around 45-60 fps there), because the PNVS is so laggy in VR the additional stuttering does not matter or bother me at all ;D

It is def. the Res. of Cockpit displays. 256 is too low for a clear picture. Beware: when changing this setting (512 or better 1024), you need to restart DCS completely. Otherwise you will not see a difference because DCS only uses the initial setting from the startup. It is a bug (or feature) that has been here for ages.

The less you use the trim button - the more you will get the SAS saturation warnings. This is the case because you don't actually reset the SAS stabilization points as stated above. And also you are fighting the SAS the whole time when not using the trim button - that is not ideal. I have a similar PC setup with dry clutch for my Warbird-D with extension and using the Virpil ACE Torq Pedals with Dampener. I am using and holding the force trim button every time when changing inputs in normal flight above 40 knots and also for the first hovering after startup. The only exception I do not use the trim button that often is when hovering is stable and just making minor changes to the inputs. When landing and below 40 knots I also do not use the trim button at all because I want the yaw stabilization to help keeping the nose on point. So better try and find a good button on your Hotas that you can penetrate very often without getting a numb thumb and try to stick to this procedure ;D Even with dry clutches you can not replicate the counter-pressure a stick would normally have in the real Apache while already trimmed. Using the trim button would release the pressure on the stick in the real Apache - so that lack of immersion on our peripherals is something we sadly have to deal with in DCS.

No issue here on my end (tested on OpenBeta 2.9.0.47168 with MT in non-VR). The mission is quite heavy (43 GB RAM was used) and I had some major short dips (1-2 seconds drops) when some scripts were loaded within the mission the first minute - but nothing too serious. Startup worked fine with the Apache here (tested blue coalition Adana). If the Apache startup works fine for you in an empty mission, I suppose there is a coincidence with your heavy mission and your PC setup.

Could you share the track-file or the mission-file please? We could test this behaviour on our own system then and provide feedback. Thx.

The rectangle on the TSD will only appear when the ASE page is not opened on the other MFD and of course there is a radar contact needed in the environment to trigger it.

You could try to learn from some real life footage from Afghanistan: This gun is simply spray and pray. I found it interesting that some Taliban survived close proximity impacts of these rounds and a second gun run was needed to deliver peace for good. As for improving skills: try to train the leading of the bullets when flying sideways to the target in comparison to the crosshair. When using the gun as a pilot I always use the default 1500 m manual range and trained the distances visually in comparison to the crosshair. Helps the consistency practicing over time. I play in VR so it is very easy to compensate the gun for movement and corrections in general - I assume this will be alot harder with a TrackIR device. Good luck.

Yep. Noticed that too. The pitch inputs are not that squishy/sensitive any more when hovering. And the pedal inputs seem to be more forgiving. Controlling the Apache while pressing the trim button is also more manageable now. I think they are on a good way with these changes for the flight model.

Weird. Have a Quest 3 (besides Quest Pro) myself and tinker with some settings recently since DCS 2.9 dropped. I do not have the issue you describe. IHADSS perfectly centered in my right eye. Running DCS MT (Standalone) with OpenXR and OpenXR Toolkit for some extra sharpening & fixed foveated FOV.

You are absolutely right. DLAA requires a RTX card. Looks like I am too long fixed with team green to assume this prerequisite is met by the majority of gamers. Welp.

Typical ghosting with DLSS - live with these imperfections or try out DLAA (this uses no upsampling algorithm, so no ghosting - only advanced Anti-Aliasing).

Ghosting is nothing new to TAA / DLSS / FSR - for superior image quality I would go with DLAA. DLAA is only Anti-Aliasing without upsampling. You need to disable upsampling methods first to use DLAA. Check out the edges if you like MSAA or DLAA more. Personal choice.