Tepnox

Hi! No, I am an Apache guy and didn't purchase the F-15E. So this problem seems to be a core issue, not module related.

Thx for the info. I am simply using Microsoft Defender in Windows 11 (fresh Win11 install since yesterday - no extra Antivirus-Software is installed). I excluded DCS World folder: DCS is always running without Admin-rights. Still getting around 2 minutes startup time on second launch with 2.8.6.41363 Open Beta MT: dcs.log Looks like I will return back to DCS 2.8.6.41066 Open Beta MT until this gets resolved internally. No other option for me right now, because I was fiddling around alot with some VR-settings and benchmarks - 2 minutes waiting time after each DCS restart is just unbearable.

This is the initial first run with 2.8.6.41393 OpenBeta - fxo and metashaders not available: dcs.log.old This is the second run with 2.8.6.41393 OpenBeta - fxo and metashaders were already available from first run: dcs.log I am using following command in my DCS-Shortcut: "C:\GAMES\DCS World\bin-mt\DCS.exe" --force_disable_VR EDIT: This in comparison is the log for the second startup while rolling back to DCS 2.8.6.41066 (procedure was downgrading to previous version, doing a slow repair with extra file sweep and the Saved Games/DCS folder completely deleted): dcs-2.8.6.41066.log

Definitely

If you try to fiddle around with VR settings and need to restart DCS each time you would think a little different, I assure you. Clearly I have better things to do than sitting and waiting for a loading screen. When you only start DCS one time the evening I would not have a problem with that for sure (despite the fact it still is an increase of more than 300 %).

I already stated I deleted the complete Saved Games / DCS folder (this includes the shader-folders) after switching the updates. And yes, I measured the average loading-times after the second DCS launch where the shader folders already have been re-established. Why should I discount the auth-issue? The auth-verification takes with DCS 2.8.6.41066 around 10 seconds, with DCS 2.8.6.41363 it is 40 seconds. This is clearly no server issue.

Hello friends. I have very long DCS startup times with the newest 2.8.6.41393 OpenBeta Update. I can perfectly replicate the issue by rolling back and forth between the last two updates - I measured the time from clicking the shortcut until the main-menu is fully loaded after second launch (DCS MT, VR and no-VR have the same loading times) - shaders folders were already re-established: DCS 2.8.6.41066 Open Beta MT: 35 seconds average (the auth-verification takes alone around 10 seconds) DCS 2.8.6.41363 Open Beta MT: 120 seconds on average (the auth-verification takes alone around 40 seconds) I already did slow repair with extra file inspection and deleted the SavedGames/DCS folder after switching between updates. Issue persists. Something is clearly off with the newest 2.8.6.41393 OpenBeta. Anyone else?

I still get the issue with Application Frame drops with very high CPU latency, even on lowest Meta settings (2784x1408 @ 72 Hz) and without OTT Supersampling. So this has to be another issue than my (previous) high resolution. @mbucchia Thx for the effort for this tool, much appreciated. Looks like I will pass and wait for full OpenXR integration. Going back to OpenXR Fixed FOV rendering for now. Good luck boys!

FOV is calibrated, disabled Bloom and Lens Flare. I will try your standard setting Oculus Home and additional OTT Supersampling tomorrow. Maybe there is some cross section configuration problem here the other way around. I don't know.

@mbucchia Can you tell me what quad view in the log exactly means? Does the image gets rendered 4 times with eye-tracking instead of 2 times? Am I having possibly a bandwidth problem with a very high baseline resolution despite the fact using a 4090 and the GPU load is not maxed out? I am quite irritated because in MSFS the dynamic FOV rendering works very well with OpenXR for me with exactly the same baseline settings.

I am using 5408*2736 @ 90Hz setting in Oculus Home. Additionally 1.3 Supersampling in OTT - this translates to 3664*3760 pixels per eye. Works great with DCS in OpenXR. These settings also work great with MSFS and enabled Dynamic FOV rendering via OpenXR. And yes, that is a very high resolution but I am a sucker for maximum clarity and sharpness - I am fine with 45FPS and ASW on and in Multiplayer ASW off. I already tested without extra supersampling but the issue is still the same.

No unnormal background activity here. These are the results with Turbo Mode off: DCS MT OpenXR DCS MT QuestPro FOV-Plugin Now the FPS gets capped at 45 FPS with turbo-mode off. I really don't understand that behavior. As you can see: ASW is turned off. This is my log for the FOV-Plugin:

I am still having issues with dropped application frames. DCS MT with OpenXR and fixed FOV runs perfectly fine. Using this Plugin (and disabled DCS in OpenXR toolkit) the dynamic FOV works with the eye-tracking but i get dropped application frames. Here are the performance graphs between DCS MT OpenXR and DCS MT with QuestPro FOV-Plugin - this is in the main-menu of DCS: DCS MT OpenXR DCS MT QuestPro FOV-Plugin Looks like to me there is an application render timing problem. The encoder and compositor stats looking fine. Any suggestions would be appreciated.

This did not work on my end. Still getting dropped application frames, even in the main menu.

Had the same issue. My developer mode was not enabled in the Oculus Mobile App. Make sure it is enabled there too!

I am also getting "choppy" performance with the plugin. Followed all installation steps, eye tracking is working and logs look fine. I run my Quest Pro with 90 Hz and 5408x2736 Oculus Home Setting, even with ASW disabled I only get around 68 fps in the main menu (should be 90 fps straight). While in-mission my GPU load only reaches around 70%. Something is off here. Are there any other performance logs I can provide @mbucchia to help myself with some trouble-shooting? To be specific - I get alot of Application Frames Dropped, this also happens in the menu.

Hi Mark, long time no see ;D These optimizations only help to reduce the VRAM (video RAM) usage - full or overloaded VRAM can result in lag / micro-stuttering in DCS. There are no real FPS performance gains to expect. You can find a thread with a whole set of optimized textures here (works pretty good - with all those optimizations you can save up to 3 GB VRAM in my testings on a RTX4090). Preferably to use with a Mod Manager: A separate downscaled Cockpit-mod for the Apache that has also some removed LOD-filtering for better sharpness is here: https://www.digitalcombatsimulator.com/en/files/3321192/ In general if you want to reduce VRAM usage overall you can also try setting the Textures to Medium and Terrain Textures to Low if necessary. As stated before, no FPS gains comes with changing these settings - only the frametime and fluidity of frames could be more stable when the VRAM limit is not reached / overloaded for your GPU. Cheers!

My superstar as well. Thank you for your efforts!

Nope, nothing there has changed as far as I know. I fly without the monocle visible in VR - focus is still the same. Regarding seat position maybe try a slow repair with DCS, don't know if something is interfering there on your end.

And as suspected, the light sources on Sinai map actually do self-inflict like on Persian Gulf. So another nice reason to have fun on this map in the dark ;D

See track attached. George AI as CPG just shoots the gun once with a burst 10 interval. If the target does not get destroyed he refuses to shoot again. Also the burst amount is not working, no matter what value (10 or All) you set for him, he will always shoot a 10 burst. DCS OB 2.8.6.41066.1 with Multithreading - no mods, did already slow repair - tested in SP, happens on every map. BUG_GeorgeAI_GUN.trk

Here you go, short clip of Tel Aviv at night on Sinai map in the Apache in VR: New landing pad: FLIR image of PNVS on buildings:

Been testing Sinai in the Apache last two days. Having somewhat equal or sometimes better performance on Sinai map in the Apache while playing in VR - in comparison to Syria. The RAM usage is nearly the same amount. In my personal view, the terrain hills / mountains look more refined and better than in Syria map. Coast lines look more detailed and have some water waves like the Marianas. The variation in trees and bushes is very good. The amount of buildings around Cairo is just insane and runs pretty solid - even in VR. But there are also downsides: a lot of terrain types look copy / pasted and more generic (maybe this changes in the early access). The small details (around houses, roads between houses connecting each other) especially in citys are missing - this still looks better in the Syria map. And there are alot of spots that are not finished yet or look unfinished (around Bethlehem for example) - the border walls / fences have sometimes weird routes and could look unfinished. In the north of the map are known Syria spots missing (special city buldings in Haifa for example, the airport Ramat David is missing completely yet). Back to the good things: The night operations are next level on this map. It seems that Sinai uses the newest lighting technology we know from Persian Gulf. The Amount of little lights in the night is insane and breathtaking. Syria at night looks shallow in comparison. I don't know if self shadows comes with external lights - need to test this. The Heli-landing pads (these are also marked on the map) have it's own self illuminating lighting that cast light onto the aircraft as a separate light source. So pretty good stuff - I really hope they can refine the map more and more with time - Syria map also got several iterations to get to the current quality level it has today. In my case, I will fly alot more night operations on Sinai map with the Apache - the mood at night is pretty strong on this map. Also the FLIR-image (saturation etc.) looks pretty solid on this map. So, I am quite impressed with the launch of the map and happy with it - especially in combination with the Apache. Did expect a much worse technical experience.

There is a pretty nice tutorial on Youtube for 3080 / 3090: Try choosing another skin inside MSI Afterburner settings (Tab User Interface), using that right now:

Yes, I checked my notes for the 3080Ti - your curve won't do anything for you it seems, looks like the default curve to me. Values above 900 mV don't matter because the GPU will never hit that mark. You can have the curve diagram opened while gaming and you can observe the current voltage output in real-time. My 3090 curve on my second PC looks like this right now: That is 1770 Mhz with 825 mV with the RTX 3090. My prefered values for the 3080 Ti have been: 750mV / 1665 Mhz - (~280 W / 75° max) 775mV / 1695 Mhz - (~290 W / 76° max) For maximum performance this has been: 825mV / 1845 Mhz - (~330 W / 85°+) -> even with these maximum settings the card used 25 W less than 355 W on default clocks. Give it a shot - I think you have alot of undervolting potential ahead with your card.