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.

Damn time flies by for sure! I remember the times in my youth playing the first time Gunship 2000 on an Amiga CD 32 console: Later of course on PC with Jane's Longbow 1+2 and sweet 3dfx graphics ;D. If i watch videos from those titles today I can't believe how bad the graphics and visuals have been - but obviously very pleasent for that time. If someone would have told me that day, that I would play in the future in real-life graphics in VR with Hotas controls like in the real thing - I would not believed it. So yea, all the nagging about missing features or better implementations in DCS beside - thx ED for making this possible! We indeed live in wild times of crazy tech, I am kind of excited what we will think about our current tech in 20 years! See you then fellas!

I have the same question regarding the screw-layout on the bottom-plate. There is a pre-review from Redkite: He posted 2 screenshots from the manual - it seems the base has some some sort of screw-mounting on the bottom, but unclear: Right now, there are no manuals / documentation available on the TM support page for this product. So it seems we have to wait or you could contact TM support (https://support.thrustmaster.com/en/product/viper-tqs-mission-pack-en/) for the manuals. It is pretty dumb of TM to have a pre-purchase right now without exact official shipping date and no documentation what so ever. If you contact support, please share feedback with us on this topic. Thx.

I can't relate to other headsets, just my impressions with Quest Pro I currently use and a Quest 2 I recently had for testing. I have no clue how MT and Turbo Mode behave on other headsets - how could I?

Quest Pro user here. Well nothing you can do about it right now. MT needs more optimization from ED - right now MT only works well with Turbo Mode on with Quest / Quest Pro. ASW is still usable but it often breaks when there is too much headroom left for the gpu and the frames run uncapped in that moment. It is tolerable - at least for me. My approach for optimization was: Tuning your settings in ST to you liking and after that switching to MT with Turbo Mode enabled. A nice bonus of MT is that the GPU load is 10-15 % less than with ST for the same frames with a 4090 - so clearly a performance gain gpu-wise. Only downside of Turbo Mode for me is that sometimes DCS VR freezes / lock up when you pause your VR session and put down your headset and want to continue after a break. Let's hope for MT improvements "in the future"! ;D

Late to the party but I also +1 that the head gets removed and gets in line with the other DCS modules. It is kind of annoying that every DCS module has it's own inconsistency or "design decisions" - there should be a baseline and standard for each module, especially the Eagle Dynamics modules! Please make it happen and possibly give more power to the users itself via a separate option in the specials tab!

Happens to me quite often when getting hit from the side by BMP or Shilka shots. Kind of funny that it's now been over 2 months and there is still no fix that got "soon" delivered. Surely ED thinks we need an accurate mathematical solution implemented for this simple problem. Sure, sure. Seems like we dedicated Apache pilots have to suck it up, no priority for ED. So same as always. Back to regular flying and enjoying the view. See ya.

Well, because the description for this sub-forum is: "For any issues with Installation, updating and repairing." So it kind of fits.

Yea well, no hard feelings here. "Obnoxious" is maybe a little dramatic in some views - the time I posted this thread it really bothered me for sure. It is kind of a drama each time hoping the next OB patch will fix issues or improve overall performance but it seems ED always wants to impress in a negative way. I get it that things will break and needs to be addressed in a future update. But the regularity of those hit and misses have a very bad taste in my mouth. I often have the feeling that ED is having a complete other build they are playtesting - if they test internally at all. I really would wish for more polished implementations of features & fixes that are solid while published in the Open Beta - not half baked implemented that needs a dozen follow-up patches. The joker cards aka "WIP" or "OpenBeta" do not help either. I am passionate about DCS and want ED to succeed with their product - but often they could really just do better. I guess they will fix this issue SOON in a future update in 2-3 weeks. So we are back in the waiting game.

Hi all. How exactly does this work for you, when DCS got updated and overwrites installed mod files? In the Open Mod Manager those prior installed mods are still shown as installed, when they actually are not. There is no way to re-install the packages (only uninstall and install). Am I missing something here? Other than that the Open Mod Manager works pretty well with DCS for me so far!

I would like to contribute some more logs. Having DCS installed and running on my second PC behaves with exactly the same issues regarding startup-time. These are the results after updating to DCS 2.8.6.41363 Open Beta and slow-repair, second startup: dcs MT 2.8.6.41363.log around 100 seconds with MT dcs ST 2.8.6.41363.log around 93 seconds with ST Rolling back (slow repair and second startup) to prior update DCS 2.8.6.41066 Open Beta results in: dcs MT 2.8.6.41066.log around 30 seconds with MT dcs ST 2.8.6.41066.log around 30 seconds with ST