darkman222

@BIGNEWYAny plans to limit the DCS.exe process only to the P Cores ( also exclude the hyperthreaded cores) for intel Hybrid CPUs for multithreaded DCS.exe ? After quite a good research on the Varjo forums it seems to help a lot of people especially people running high end VR headsets that show spikes in CPU frame time with hefty stutters. I have been testing this for 2 weeks now on multiplayer servers that showed that behavior when getting close to other players. It had a great relief on my CPU frame times and no stutters, if it was caused by LOD switching related stutters. Edit: Maybe a checkbox in the settings to bring DCS to P Cores only would be a helpful addition for users. Also a separate toggle for exterior texture (jet) and interior( cockpit) resolution would be helpful to reduce stutters.

Gotta send your complaints to General Dynamics or Lockheed Martin. Obviously thats the way it is in the real jet.

I would not already call it: "Thread successully derailed" but how about a separate thread for the J11 and FC3 russian fighters? We are talking about products that are currently developed by ED (yes, early access) that get new features added while existing features break more and more, not getting fixed for months or even years. Especially if it is a really obvious bug that gets pushed out into a patch. It would not even be a big deal if whats broken did break on purpose thus it gets mentioned as "known issues" If ED does not want their devs to spend the time with in depth testing, there are enough people here in the forums that do so. And who are willing to give bug reports tracks and spend a lot of time doing that. Me included. But if the thread goes to "reported" gets locked and stays like that, together with the bug for a year. Thats not the kind of motivation these people need. They simply help because they want the product they purchased to work again.

Well the question is: When another jet is STT locking me in the F5 and my RWR just does not do anything, is it considered: -Correct as is -Broken -Fixed and broken again -pending fix What ever it may be. It is pretty useful knowing if one is being STT locked... Even a Mig19 with a way more rudimentary RWR has a sound for STT lock.

Sorry for this extra topic for such a simple question, but there is so much threads about the RWR, being right, being wrong. Has been fixed etc. What is the latest state about the F5 RWR? Having flown the the more modern 4th Gen jets, that all will give a RWR warning when being locked in STT by another jet, it seems like the F5 RWR can only give you a sound if you get nails by the jets around, at least for the first time RWR detects them. But no RWR spike for STT lock? Can I do something about it? Or is it just like that by design of the old RWR?

Found the reason. When I run DCS without DFR it runs without Turbo Mode. When I install DFR and disable turbo mode (in the config file) I get the same micro stutters like when I run DCS in OpenXR without DFR. What exactly does this turbo mode do? When I disable DFR with the no eye tracking option , I can even run it in a higher resolution without stutters compared to SteamVR. null

The mission in which it crashed for a lot of people was in Syria. At the moment I can only confirm it happens on the Syria map. I can give it a try on Caucasus tonight maybe.

The squadron I fly with, last week had a mission with the use of GMT (ground moving target) Radar involved. 4 out of 10 Vipers including me got a crash to desktop. We tried to find what caused it. And its no specific action on the GMT that creates the crash. I could reproduce it just slewing the radar cursor around, after locking and unlocking, while having the TGP on the other MFD. I have a SP test mission with which I could recreate the crash. When it crashed I took the dcs.log and extracted the track file. It crashes again if you run the track file. It also crashes on a different PC. My main PC is an i9 13900KS and and the other one is an i7 11800H laptop. Interesting to see is: -On the i9 it only crashes the first time DCS is run after a boot / reboot. If you dont reboot, the second time I run the track file it does not crash. -On the i7 it crashes every time I run the track -on single threaded it does not crash on any system. I have attached the DCS Log from the crash. And extracted the track file: "dcs.20240609-144443.trk" if other people want to see if it crashes their system. Also see the system specs of my both PCs dcs.20240609-144443.trk dcs.log-20240609-144443.zip

The F4 is a different beast, concerning performance. This thread is only about stutters appearing to LOD switching, VRAM, caused by other jets coming close to the player.

Please dont hijack threads, especially in bug section that are not the exact same issue youre seeing. I even updated the thread title twice to make it clearer what it is about while I was investigating. Create a new own thread, or post as a question in the general F16 section please.

Seems like the F16 keeps the delivery mode of the AG ordnance that was previously selected. Seems to affect many if not all AG weapons:

Someone has done it: I already put in the comments that Charlie Sheen and the DCS community wants this jet.

-Fixed: Сrash when switching weapons when using unlimited weapons According to changelog ED has been working on the F16 weapons in general. But nobody at ED tried to fire 2 different weapons in one flight I guess. That bug is way too obvious to be overlooked if someone at ED really had tested AG carefully before the patch was pushed out. Otherwise it should have been mentioned as: Known issue.

It does not even end here. You can have Harms in CCRP, CCIP and DTOS. Reproduction: -load Harms and MK82 -AG mode -MK82 are selected first -switch to Harm -> Harm show what ever mode was selected for MK82 before CCRP, CCIP, DTOS Track attached Conclusion. It seems not to have something to do with Mavericks As long as the WPN page is not shown, switching the AG weapon via SMS page does not open the corresponding delivery mode for the selected AG weapon unless WPN page is opened up harm in CCRP CCIP.trk

Whats even more awesome, now I can use HARMs in VIS/PRE/BORE mode aka the other way around also works. Reproduction: -Load Maverick and HARM -AG mode. ( toggles to Maverick first) -SMS page, switch to HARM -> Harm shows PRE mode from Mavericks. You can toggle back to Maverick. Toggle between the Maverick modes and bring them to the Harm MFD. Maybe that was not as obvious as the original issue here, because if you open WPN page it switches back to HARM mode, how you would expect it to find. harm in mav modes.trk

Reproduction HARM: -Load Mavericks and Harm -Fire Harm -Use SMS page to go to Maverick -OSB button that used to show VIS/PRE/Bore now shows HARM Reproduction CCIP: -Load Mavericks and MK82 -release MK82 -Use SMS page to go to Maverick -OSB button that should show VIS/PRE/BORE shows CCIP and is stuck Track attached maverick in CCIP.trk maverick in Harm mode.trk

Thanks. Update was released. Can not find the toggle in Varjo Base though. Maybe it was for the other headsets but not the Aero?

Thanks for the video. Any statements by the ED Devs? Still tagges as "track replay needed" @BIGNEWY

As far as I know Open Kneeboard is not module specific. You can even use it in MSFS.

If a feature (that is not currently worked on ) is in the game it should remain functional. Of course working on one end of DCS can break another. But users rely on avionics or systems that have been working before. Often a bug is already visible after 15 or less minutes of play time. If ED relies on the users as testes that much, take it more serious with reported bugs. And adress bugs, fix them that the module remains functional in the way that people have been using it all the time. People are just asking to keep the integrity of what we already have in the game.

You have a pretty similar PC as me. Try the following. Download process lasso. And disable hyperthreading as shown in this image: Restart DCS and see if DCS CPU affinity gets these CPUs tagged like that: For unkown reasons you can not achieve this by disabling the efficiency cores and hyperthreading in BIOS. Also starting DCS with the "affinity" argument does not work. Let me know if that helps. If you want to know more about what I found and tested already about the micro stutters look in my thread about it here. Like I said. If you tried it ( process lasso is free) please let me know.

I am aware of that textures loaded from the SDD into RAM also can lead to stutters. ( 64 GB memory are ordered btw) But in my testing, you can see in fpsVR that my memory is way below the limit and no factor. @BIGNEWY@Lord VaderI waited a few updates now for a final test and some conclusions here. My test is like it was from the first time I started testing: Approaching a Gazelle over the ocean. (see the video above how I do it, you can also download a track file of it) I could have used another aircraft to fly close to, but the Gazelle seems to have the biggest impact on CPU frame time and texture loading and unloading. Here are my inital tests about in which version the issue has emerged. I used the DCS updater to revert to older versions. So its all with the same hardware and drivers. Tested on the same day. No change in hardware or drivers affect that test this way. Note: In fpsVR see the graph for individual CPUs, that with 2.9 DCS seems to start using the CPUs more evenly than it used to in 2.8. More about it towards the end of my test. This leads to another test how to improve that behavior. A lower texture size of course helps people that are affected by it, but as long as the texture slider is for all textures, including cockpit textures, it does not help in the long run as long as we dont get separate sliders for cockpit and exterior textures. I still wanted to share my test up to this point as this might give some further insight, without being a solution though. Here comes my most important test. I was trying a method mentioned by Jabbers in his testing running DCS with arguments: --affinityF (4 cores) to --affinityFFF (12 cores) That did not help in my case. It made DCS run unstable. Possibly because it disables random cores. Then I used process lasso and clicked "disable hyperthreading". That also disabled the efficency cores. Note, this only works with process lasso. Disabling the hyperthreading cores and efficiency cores in the BIOS also leads to an unstable running DCS and even the entire PC runs unstable. The only way to do this is with process lasso. Now DCS runs only on these cores ( note the efficiency cores are also disabled) : Now here are the results. The stuttering because of textures loading and unloading into the cores / threads is completely gone. I tried ( multiple times, but without success) the MT.lua @BIGNEWYposted in the thread he started called: "Intel hybrid CPU Getting stutter? Please try this in multithreading DCS" but it did not help. Not sure if it was rather to fix core parking issues. Also it took me this long to figure that solution out because disabling cores via BIOS is no stable solution. Sorry for the long post. But I felt that I needed to share these results in detail, as I spent quite some time gathering them. I included a ZIP file of my system specs, a dxdiag and a dcslog with "allcores" and with "8cores" in the file name. So you have a file that was created using all cores and a file that was created when DCS just used 8 cores. As requested, I included my GeForce settings too. But I dont thing they matter and they are just the plain default anyway. Also a track file is attached. I am not really sure if you can reproduce it on your systems as this behavior is barely visible with the DCS fps graph when trying this in 2D. Running DCS on a high resolution VR headset is of course demanding for the hardware and clearly shows if something is not running smoothly. I am willing to help with further testing for ED, trying LUA files or whatever needed. For now this is a satisfying solution as long as nothing changes and I can keep the performance using this core affinity with process lasso. dxdiag_dcs_log__geforce_settings_hardware_darkman222.zip stutter8cores.trk

Not only the target designator box in NAV or Missile mode have low refreshrate. Also the target designator circle in STT DGFT mode has it. ( see track replay) So if you go for footage on youtube with the NAV mode selected, you will of course just find footage with less erratic movement of the jet for NAV mode. But here is a good one at 9:27 with the target designator box: Easier to find footage of the target designator circle for DGFT mode. You can see, neither in NAV nor in DGFT mode the refreshrate of the TD box or circle is so low refreshing as the DCS TD box is. TD box and circle low fps.trk

@Stroke 3can you reproduce the last one in a single player track replay? Might be related to my thread about the gun pipper with bad refresh rate which is permanent and not only occasional. My thread has been locked December last year, although it is shown as investigating and reported, the issue never has been adressed since now. Also me and other people recognized that the HUD ladder and FPM have some jumpiness since the last update. But very rarely and not reliably reproduceable tho. Seems like the bad refresh rate HUD symbology makes it way into more HUD elements with every update.

Thank you Mbucchia. Although Varjo Base now shows the desired stereo render method, the performance to quad view did not change. Unfortunately the performance of OpenXR compared to OpenVR with SteamVR is in general worse with more microstutters. ( In contrast to that OpenXR on the Pimax performs better than openVR) Should not native OpenXR on the Aero also deliver superior results compared to OpenVR? Application CPU and GPU are well below 11ms frame time. If I am not mistaken I need 11ms for 90Hz refresh rate. Why does it give that microstutters. The frame rate just goes up and down from 89 fps -> 91 fps and down again. See that with openXR and SteamVR the graphs are more stable. Except some spikes there is a steady 90 fps in the GPU graph. I was hoping to gain performance with openXR, but the opposite seems the case. Its the F16 freeflight mission, I always use for testing.