Pikey

Hi thread. Well I would love to say the problem isnt there, but for the first time in months I crashed my HMD during a testing session. Black screen, SteamVR did the oh no! message and dcs continued to run a sub 5 frames in the mirror view. Hard alt-f4. Began with poor frames only swapped planes once or twice, all ww2. This was on Channel map which is pretty hard on performance. Nothing I hadnt done before fine, same mission, less players. I do recall considering if I could be bothered to do my normal restart before the session and foregoing it. Might still be about vram. It didnt happen again so it stood out as a bad session inside a normal evening. Nothing was really in common and it didnt give me any clues. Still feels HW+driver related than DCS. I think DCS provokes the situation, absolutely, but its really nothing to do with this crash. DCS has to be the only commercial software I know that can collapse your PC's hardware and you can set it to do that, or give it workable settings. Side note... this is not owned or accepted as a bug with DCS until its a problem with its code. At best there are multiple performance issues. The ED developers have nothing to fix until there are reproducible steps that they can see and get the crash themselves. I'd be delighted to reproduce and champion a software bug. Everytime I try it resists, then out of th eblue, reminded me I was not looking for it. I strongly suggest ruling out a bunch of issues by using conservative settings and reporting on the frequency of the SteamVR crash. PD 0.7/0.8 Massive savings. People already found that in game PD was very expensive and should be traded for Steam SS at every opportunity. SS 150% is behaving well for me, I went over that and began to induce performance slow down. Textures... maybe, I have tinkered and medium or Low works better than High. MSAA off. Here is your sacrifice. Terrain distance could be anything, try to keep it higher for horizon and light popin reasons Water has to be high, game broken without it. SHip wakjes go, etc. rest of it is fairly inconsequential Until you run the game in VR at lower settings successfully the settings are neither ruled in or out. It's just a game of ruling things out until nothing is left. I accept settings might be contributory, but I since I cannot achieve your crash rate at your settings, you should try to change your crash rate at my settings. Because the actual settings might have nothing to do with the frequency or liability of the SteamVR crash. If we rule out settings its a vast item to cross off the list.

Hi again. I watched the videos. I had about four new thoughts. :( 1) Very cool to see code I wrote in Jan 2018 reused in stuff you fly today! What was that mission? I remember trying to put together the mission naming conventions and looking at my wife playing World of Warcraft and picking out a bunch of nouns for the random table that were either animals or classes! 2) You have used SteamVR beta 1.15.x in every reproduction. I have never gone past 1.14.16 and after watching this, I feel I dont want to update. If you want, try that. It's soemthing, I dont hope. 3) I still dont know your PD setting. 4) Your setup is somehow broken worse than I even thought. I'd rather get you working than continue this torture. I can't hope to get anywhere as close to these headset steam VR crashes. Mine can wreck my game, but the headset hangs on and as long as I just clear down the memory, it will be fine without ever disconnecting or crashing steam VR. There's something fundamentally wrong. Whilst I can get my machine to stress and slow down just as easily, the primary difference that seperates me and you and perhaps others, is the SteamVR crash which causes the VR device to actually get disconnected. I dont have your setup, I have WMR for Steam, WIndows Mixed Reality Portal, Steam VR and a HP Reverb. Even more junk in between. Those vrcompositor messages... I have none. "Failed to wait for GPU work". Nope. its not remotely similar. I'd be interested if this is hardware related messages or I could get them on Reverb. I know you said you could do this on Oculus, but this is absolutely more about the VR softwares reaction to DCS than anything else. I think it needs someone using an Index and even get on identical versions of the middleware. Frankly, if I thought you reproduced this much, after giving up with reproducing, myself, I'm kindda worried you can't actually get it working reliably again. Can you? What would you do to enable that? I know you said you avoid the situations, but there were quite normal dogfights there and you arent lasting 20 minutes. Generally I have to fly for 2hours for our sqn missions. I realise we use VR differently, I was testing use_shared_stereo_parser = true today and all my CPU and GPU were in the green once airborne, a tad of orange scattered through it. 45 on the ground 30-40 on SC, 60-90 FPS in the air in small missions. 0.8 PD 140%SS no AA, medium textures. I couldnt get over 22FPS at the begining of the year. I just wonder if its not just better to get good frames and experience than hunting this? Let me know how close you can get to normality.

I can live with it, but I did find the text small, some space wasted and a lack of straight lines means It feels a bit unsettling on the eyes.... lack of horizon? Like the feeling you get when your taskbar in windows disappears... It feels busier... harder on the eyes. I zoomed in to the screen quite a bit. But after ten years, I'm surprisingly up for change. Best not tell my wife. Anyone considering using the blogs?

C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_feed726c6560f7a7\nvwgf2umx.dll is the faulting module. nvwgf2umx.dll is graphics related. Review your GPU drivers, do a driver clean and update to latest, then load the game on some lower settings that dont crash inside of 30second then build up until/if they crash again. A diaxdiag submitted would help diagnose but likely wouldnt change the first advice to you.

Hi Buddy. It might be time to take a little break from this so it doesn't consume you. There is a tonne of data here, thanks for the responses. Actually something has surprised me here in the depths of the detail and it's weird and its the top most thing that came to mind, from the innocuous question, "Are we troubleshooting the same thing?" Well, apprently your "black screen" is not the same as the one I've had 3-4 of in as many months.^^ This took me by surprise. The HMD itself appears to shut off, the lenses go black, black like an unpowered device, not like a black screen but with an obvious backlight. Does that make sense? I'll try to adjust my capture, might not be as pretty but the one thing you aren't seeing is a little window appearing over the steamvr box (that can be seen in orig) that states SteamVR failed. I tried to set OBS to grab it, but short of just capturing an area of the desktop you can't. Based on what you're saying I see the value in doing so and lining it up against timing so I'll adjust accordingly for next test. That reminds me of a Rift thing way back, but what I have seen is DCS get disconnected the helmet goes black, but it enters the basic "grid" view and tracking is still functioning. Yes makes perfect sense, its a "powered blackness". To answer your question on how to record inside the headset, I use OBS + SteamVR plugin for OBS to record the view directly - what you see is what you record, except some trimming to 1080 ratio. As something of a comfort, the way the problem is now defined is both useful data and indexable by Google for other headset usage too. So it might be a lot of work, but its for the communities benefit. I still need to review this after work, especially the videos. This is now heading in a direction especially by the frequency and ease of reproduction, that this seems to be not something in DCS at all and may even be in the realms of hardware behaviour. You shouldn't consider that as some sort of failure, no one is pronouncing death of anything, it just seems to be building a picture that way and that's my current opinion for all that's worth. I'm going to take another shot at this but try to get closer to your setup based on what extra details came out of the reproductions you did. I also will see if I am missing something. My last question is, "with the amount of success you had reproducing this, and the variations you tried, what is your revised steps to reproduce?" Can you iterate on the version I tried or is it the same? If I can get that, then I can get the folks I do testing with to all try a fixed process and feedback, it will definitely help make the picture more visible. A final comment. It sounds unplayable? Is it? A bit of reverse thinking here but... what settings actually work? I'll check back in later today or tomorrow, whenever i get the time to review the videos.

Amazing! Excellent! Right, now we are cooking on gas. So we can get a reproduction but it still seems the mission is at least a little in play, which is a concern. You are right, my mission is not as complex as TTI. That's deliberate, we need to make the miz as simple as possible, avoid code, it just confuses the issue and ED wont accept mods and scripting, they are pretty fussy on that, but I believe we don't need mods or complexity to reproduce it. However, if you can think of ways to generate this condition faster using the same mission, or even much smaller, let me know. So I have lots of questions! 1) Is the problem defined as DCS 'crashing', or the HMD crashing? Or ... as might be the case, is DCS crashing because the WMR crashed, because that's normal and I can repro that by leaving it to sleep for long enough. Sorry to return to the problem statement but I was under the impression the fault was the HMD going "black" with the DCS mirror still renderign away like in the OP. Please clarify, it's pretty important. If I had to guess based on what I saw, SteamVR decided to give up. DCS logs closed normally, Steam says it was unresponsive and detached. 2) Do you have the lighter mission, can you remove the A4 mod and refine the steps so as to get this to happen faster? You dont have to, but if you think you can, it's best for simplistic reproduction. I think we are learning here how to make VR crash, so eventually we should be getting the steps shorter and clearer. 3) On your DCS options picture, this is a perfect way to share the settings, except when I read them, it generates a question because MSAA is equal to 1 and we all know MSAA starts at 2x. Can you verify this and any similar oddities please? Is it 2x? 4) Starting SteamVR Home launch beacuse system.generated.dcs.exe exited after 480.214270 seconds This looks like the point of the crash. Can you keep an eye on that line on every crash to see if this is correct. I think steam is saying that it cannot get hold of the DCS.exe process. Which, let's be honest, sounds about right when the system becomes unresponsive. I think this is the cause of this "crash" at least. But this throws everything into confusion for me. I thought this was an HMD crash. 5) Why are the videos ending with DCS still running, but the logs show DCS recieving a shutdown command? I'd really like to focus more on the last seconds to understand exactly what is happening to you as I am not sure I even know the problem description at this point with certainty. 6) Which log are you tailing in the video? Doesnt seem to match the Steam ones you put in the zip :( 7) Are the DCS logs you attached synched with one of the videos you uploaded? If so please indicate which one. This log shows a normal DCS shutdown. That's thrown me, i didnt expect that at all (am trying to reproduce steam closing DCS right now.) 8] Do you have the Steam VR setting "Fade to grid on app hang" on or off? 9) DCS Logs review. I've got plenty to discuss and ask from you at this point, theres a lot of logs that have aroused my suspicion and need to be ruled out. Here we go a) 2020-10-17 21:05:29.480 WARNING DX11BACKEND: Shader posteffects/nvd_hdr.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/posteffects/nvd_hdr.fx is modified. 2020-10-17 21:05:29.736 WARNING DX11BACKEND: Shader effects/pfxdust.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/effects/pfxdust.fx is modified. 2020-10-17 21:05:29.950 ERROR EDCORE: Can't open file 'bazar/shaders/posteffects/slot.fx.' from fs 2020-10-17 21:05:29.950 WARNING DX11BACKEND: Shader posteffects/slot.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/posteffects/slot.fx is modified.This is a no-no, can't be having custom shaders and reporting bugs. If you aren't aware of what you have done/modified then perform a repair, it's just going to be the first thing ED say and they wont touch this with someone else's ten foot barge pole ;) Compiling on the fly causes a lot of extra load. I always recommend loading a mission after a new install and tailing the logs whilst loading a mission with every unit until the logs run clear. Is that what you meant by having lots of unit types? If so... something to consider. b) 2020-10-17 21:05:37.305 DEBUG LuaGUI: can't open './Config/Input/UiLayer/keyboard/Keyboard.lua' 2020-10-17 21:05:37.308 DEBUG LuaGUI: Input: can't open './Config/Input/UiLayer/keyboard/Keyboard.diff.lua' these and then pages of issues with your inputs, I do not understand. It's not normal. Probably not important, but I thought I'd point it out. c) Make sure Tacview export is switched off. I had huge performance savings with this, I ran it loaded but not doing much. TwitchtoDCS...I'm not happy with this one as I can't verify it works OK or has no effect. If you can comment him out during testing, that would be great. I believe there is a hook involved to the screen at least. d) Your pagefile is half mine and I dont mess about with pagefiles. Not good when we are using all the 32GB, right? There is always usage of page files if they exist, for every pagefile removal top tip, I'll give you a broken VMWare Admin having an argument with Microsoft. Don't manually configure pagefiles, it never helps. If you want, put it on another fast disk not used by OS or Game. Mine: 2020-10-17 13:19:02.717 INFO DCS: CPU cores: 6, threads: 6, System RAM: 32699 MB, Pagefile: 29770 MB Yours: 2020-10-17 21:05:13.846 INFO DCS: CPU cores: 8, threads: 16, System RAM: 32715 MB, Pagefile: 12800 MB e) The pylons mod - VARS. I reported a graphical glitch with this... night time lights were screwed: Check oil platforms. I dont trust it and its been off my HDD ever since i looked like an idiot reporting it to BigNewy and no one could reproduce. Same advice applies, it does more than is says on the tin. f) Gave up counting the other mods, but if we really want to compare like for like, you need to get much closer to vanilla. There's only one thing you need to know... mods can and do screw with things in interesting ways that you would have thought completely illogical. I'm not saying anyone of them is causing this, but whilst its in doubt, test vanilla for your own sanity. You've literally got every single one that is well known and even some I wasnt sure of. It's unhealthy for the support process of comparing like to like. g) 2020-10-17 21:07:14.393 ERROR DX11BACKEND: Can't find precompiled shader enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;. 2020-10-17 21:07:14.393 INFO DX11BACKEND: Compile shader: enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1; 2020-10-17 21:07:14.432 ALERT DX11BACKEND: Error: Can't find precompiled shader for effect enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;. Recompilation process will take some time, please wait (this situation should not occur on end user PC, if there is no manual shader editing)raycursor.fx glass_instrumental_material.fx A couple of these. Is this a recent reinstall? You shouldnt need to be compiling shaders on the fly unless you've only just installed DCS and have no shaders precompiled. This is a sign either of some shader tinkering or a new install or you saw a texture shader that you hadnt seen before, which is kindda odd. Again, vanilla, you cannot guarantee 3rd party changes are great from version to version. ROT: Tinkering makes it worse ;) h) Last but not least: 2020-10-17 21:13:15.224 INFO DCS: application shutdown Graceful shutdown, nicely logged. I've no doubt that part of the cause is DCS doing something, but its very much pointing on this log set like Steam killed DCS, rather than the other way around. Next steps I need to resolve some information about which logs matches which video. Especially the dcs log with the 'normal shutdown', the Steam log, which is in the video but I cant find in the log bundle you sent. I could come up with an early hypothesis that Steam is closing DCS when it doesnt see it. This doesnt make sense, maybe DCS closes itself when it doesnt seem steam, I am not a developer so the last seconds before death are pretty important here. If possible, see what on this list you can take action on, especially with creating parity between a vanilla install and a supportable installation, that's important and not too hard to do. We also need to resolve the exact problem statement. I thought this was an HMD blackness and the mirror still existed and DCS is running fine. Now its not clear anymore, it sounds like dcs was closed. Please, that's super important, we could be barking up the wrong tree there ;)

I'm only interested in the precise steps that do it for you, im not interested in if it crashes for me, you are guessing ahead too far and not understanding the purpose. If you crash and I dont, I change my config to yours. I've explained this umpteen times now, don't overthink any of this. We need to have a baseline to work on. Guessing with statements like "A mission like TTI" doesnt work. I dont even know what TTI is. Statements like 150-200 SSS doesnt work either. Say what number exactly. To answer the question (i think...its difficult to understand it) After running settings that gave me 9 FPS I'm not sure of the value of running the sim at these settings. VR has and always will be a trade off between performance and visuals. That's a given. But that's not for me to say, that's for ED to decide to say if they support such a setting. If it reliably breaks the HMD then its still useful information, imo. But its still not useful for people in general.

So I ran the above test today and whilst YT is still trying to do the higher res version, it still shows how hard I pushed the PC. I did everything. I made my computer burn. The stench was concerning. I could hang the entire computer for minutes at a time but the HMD was still fine. I did this for 30 minutes, reloaded and turned the settings back to the workable ones with the video still recording. No HMD crash. The only thing I can conclude is that this is not stress or texture related at all. The more obvious conclusion is that you require to run settings that will not be running DCS well so there seems to be little point in actually running DCS at these levels, at least on my hardware. Give me steps to reproduce, I can't do anything more to help.

Since no one is going to provide steps how to get the HMD to crash I will have a last attempt myself and invent how I think it could be done. I'll take textures and set them to high in both cases to force much higher VRAM shuffling. I'll add MSAA 2x because I saw someone else talk about this, but I dont know why you would add MSAA and Steam SuperSampling, makes no sense, but.. I dunno. I'll bump Steam SS to 200%. I'll create a mission with 1000 units. Mostly so others can use it and see if it works for them. I still think the exact mission would be better but since there were mods and it's some scripted server based mission its not a good start point. I will make sure to concentrate on SuperCarrier, F-14B. I'll invent a process, because throughout 9 pages of people saying they can reproduce on demand, they cannot produce a step by step guide how to do it. The process will be (until someone wants to provide one that actually works): 1) Configure the graphics settings as per my original video with the changed of textures high, MSAA 2x and SSS 200% 2) Load mission attached from the Mission editor 3) Enter blue slot and take the slot on the top 4) Wait until the cockpit has resolved loading and press F10, zoom in scroll wheel on the map, press F2, F3, F1 then ESC 5) Pick the next slot down from the last and repeat step 4 6) Continue steps 4 and 5, cycling through slots waiting for the HMD to go black and crash. With problem reproduced supply accompanying DCS trk file, DCS logs, dxdiag, Steam VR logs (as per Rob) and as much info as you can find and post into this thread Reproduced with the information attached. If no one can reproduce, then come up with some other steps that do work for at least the people reporting the issue. FWIW didnt work for me, I just got an unplayable game, frametimes exceeding 100ms and a pointless excercise of deliberately trying to break my game and working settings because what else can I do, no one else seems to want to do what needs to be done. Will post the video later. VRHMDcrash.miz

Yes we do need to settle on a mission and very specific steps. It doesnt matter that I cannot reproduce whatever you can come up with based on the mission and steps on it's own. If you think that, then, you are thinking too far ahead and not understanding the process. The fact that one person gets it and another doesnt't is fantastic, but only if they both do the SAME thing. Perhaps I need to explain more to get you guys involved in the troubleshooting process. If I can repeat exactly the actions that you do whilst crashing the HMD, then we know for 100% sure that its not what we do, but the configuration. T/S is about ruling out all the possible, until you are only left with the cause. But we already told you that Pikey, the mission doesn't matter! Maybe! But How am I going to tell anyone else how to reproduce if it only happens with me and not someone else? It will only serve to perpetuate the insanity of leaving each person with a problem to define. It is absolutley reasonable to ask for the steps from someone with the problem on demand. I appreciate you are jumping way ahead to a very distant hypothesis... it's VRAM usage, turn your textures up. Work through what happens if for example I pick any mission and process then turn my textures up? And I don't reproduce? Or I do. I have actually taken my own settings and it's my bug. But no one else has the problem, so I have to give my steps to reproduce and submit it as a bug. To which someone says... I can't reproduce... and I say, well just pick any steps and any mission... and so on in a circle. Please, steps+miz.

I don't know how many times I have to say this. I cannot do what you are saying is easy. I do not know how. I need steps to reproduce the issue in order to log it to a deeloper to have them also see the exact same thing. You said it was easy. Treat me like an idiot, please, and tell me what to do step by step to crash my HMD. Once I can do it on demand like you can I can report it and that is that. Will you? Please?

still no steps... What do you want me to do? I could say to ED, hey this is easily reproducible, go ahead and reproduce it. And they will say, "How"? Don't you see the point of this?

So now itsnot specific to a mission? then I cant provide specific steps to reproduce. I'm not taking part in guessing games. I cannot believe I've asked three times for the same thing now and no one in this thread can give specific steps to reproduce something that is apparently affecting so many people. Are you absolutely sure this is an issue?

I need the mission. The OP has a mission but it has mods in it. That's not going to fly down the line, so it's out. Can you specifiy.. single or multiplayer? Can you specifiy, what settings? You said mine were too low. I dont think they are. What is the specific thing that makes the VRAM used more, I can't assume I know that or it's the issue, leave nothing to doubt. Is it the SS in steam? I had 149% set in my 20 minute video. Imagine you are trying to teach your mother how to execute a xsite SQL injection hack on a server. Give them the exact details. :) I'm trying not to sound like a broken record but this process WILL work because it gets your mind focused on what is required to encapsulate the problem. Too many people coming by and saying "+1" and being of no help, too much chat, too little data. Dont try to solve the issue, just allow the issue to be experienced by anyone with simple instructions. I wouldnt ask if I didnt need to because my video demonstrates I get 60FPS cockpit switching, F10 views, and it's fantastic and thats the setup I want. We want a mission, a set of instructions, with any config and nothing left to misinterpretations. The testers will validate that, it WILL get logged to Jira and seen to by devs once it works, but none of them, or us, can reliably reproduce, even if I do recall a couple of crashes myself. Nothing like everyone else though, so it must be some huge difference between my config and others.

Alec can you help with the steps to reproduce. Also you said I need to increase my settings. Which settings? The OP has said someconfusding things like he can get it to happen nearly all the time, but he doesnt say how and it's muddy around this point. Just to be clear to everyone what steps to reproduce are. Looks like this: 1) Use these settings and confuiguration: List of settings required to make it crash 2) Load this mission attached in VR as if you would play 3) Take this slot. Do not wait, take this slot 4) Repeat step 3 until the HMD goes black Please do not try to troubleshoot the issue. We are stuck in the game loop without access to code. The next step is to give the steps to a developer who can then have the code in front of him and step through the process with a debugger. All our conversation is not helping unless it is giving steps to reproduce. To make better code, the dev doesn't need to know anything except how to see the fault. The tighter, the shorter, the least complex, the most specific, the better. I'm sorry this stage of T/S is so boring but this is what it is. Yes we know... it's not easy. Also you need to know, you will get very little feedback. Most fixes don't even get a mention in changelogs. This is normal, it's an unsatisfying process. Try doing it for years :/ Steps please guys :)

You need to do what I asked. Don't worry about percieved tone. Steps to reproduce. That is all.

I take this very seriously, I have spent hours on it today. Here we have the heart of it. What conditions? It's never said. This is why these threads don't do well. We need steps to reproduce. 1,2,3, BAM And if these cannot be found, the thread just collects random people with a broad range of issues and becomes a dumping ground for performance related stuff. You said: • Using the F-10 map, especially if toggling quickly • Switching modules, especially to the F-14 and ESPECIALLY when it’s on the Super Carrier • Bringing up the VR overlay (Steam or Oculus) That's not steps to re produce because I did that and it doesnt happen. All except messing about with VR overlays. I'm not accepting playing with overlays is any part of proving there is a bug with DCS code, leave it alone, its not part of the problem. I spent hours today producing proper data and succeded in demonstrating that DCS is performing absolutely amazing in VR. I never set out to do anything but make it crash. Frankly I think Steam VR and WMR is absolutely dogpoop, based on it crashing without DCS and it losing tracking, losing two axis of tracking but not others until reset, some builds in Steam better than others etc. Yet today it behaved and recently that's my findings. Seriously that's all I can show for it. You attached a mission. You never said that is part of the reproduction step. That's important. I made a video. 20 minutes long, on a 1300 unit multiplayer server, entering multiple cockpits, checking F10, all worked perfectly. No wait... surprisingly bloody amazing considering the state it was in in March. 60FPS in VR, with shadows, cockpit shadows, extreme distance, in multiplayer, with a 1300 unit mission. On the cheapest 2080 I could find for sale. And I was recording, in 4K, no downsampling, in CQP level 14 bitrate on Max quality profile at 60 frames. It's taken me the best part of today to edit, compress, render, upload, and i'm still waiting for YT to actually process it. This isn't evidence that says you dont have a problem, or others dont, I believe it, I really do. But you have to show us why this is a problem with the game and not something you did with your computers, because there are many others who dont have issues or at least not without the same ... Conditions ... And that brings us back to... What ... Are ... They? Show me, I will follow. Steps to reproduce, in the simplest form, exact, no guessing, a miz, I can host if its only multiplayer. You never even said it had to be multiplayer in your OP. Here's a bug report format: Description of the problem in ONE sentence Steps to reproduce 1,2,3. Expected outcome Actual outcome Data, like a mission, a trackfile Everything else is just conversation and distraction. Sorry. Loved the post really :) But I know developers, and they don't love this type of post! So. If you use the mission you attached to the OP, does it work immediately or straight away? Do you have to go between several cockpits? How many? Specific ones? Do you have to fly from a certain slot in a certain place, whats going on in the mission? Does the problem happen all the time? If not... you do NOT have steps to reproduce, something else apart from the steps is occuring. That's what has to be identified.

I've just tried to force this to happen and I got a 20 minute long video with perfect F10 map scrolling, FPS 55-60 in cockpit as reported by game and FPSVR, GPU remaining in the orange times at 15-16ms frametime, CPU in the green and no issues. I think I had two micro stutters after loading the Jeff but I went through f18, 16, 14, Jeff, 21 and F10 on each and it's just not happening. There was a brief period where my frames went to 22 for some reason until I swapped aircraft but when I came back to the same aircraft after another, it returned to 55-60FPS. It might have been the recording process. So best to explain the steps to reproduce exactly and I'll return my findings. This include configuration in detail.

Not sure if it helps but i was asked for input. I have Steam VR with an HP Reverb, i5 8600K, 32GB RAM, 2080Super and I run DCS on NVMe which is different to my OS (Samsung SSD, Samsung EVO plus 500GB) I see a period of stuttering when first moving to F10. There is definitely somehting to optimise there. It seems initially worse than subsequently, like new texture load. I have 3-5 occasions (didnt count), in the last three months where the HMD crashed and went black but the game continued running. These werent connected with anything specific that I recall. I never had anything like that on Occulus, this is a crash of the HMD software, but the cause I couldn't say, If I were to make a wild guess I'd say it was high system usage causing something to break on the VR side. I am saying, whilst I see very little crashes, these are not at all common, and i regularly prepare for multiplayer by restarting my PC and shutting down extraneous applications. I'd be happy to work with ther OP in a like-for-like example with steps to reproduce with the aim of getting reprodcucible steps (OP video does not reproduce for me) but I cannot engage in performance or tuning related guesses with optimisations and tweaks as a solution. The game is already being iterated on monthly, if it's not clear cut where the issue is there is no point everyone keeping on saying "+1" and adding no data, people need to be VERY specific, provide exact steps and configurations or this is just doing circles. Thanks.

I don't know of multiple ways, I only know that an event handler looking for th eunit ID would be the most direct.

Entirely incorrect. Firstly Scripts only run on the server. Secondly they cost milliseconds in time to execute, tenths for large frameworks like MOOSE, which only ever run when no one is on the server. What you see is large unit counts, perhaps units spawning into the game (again a DCS thing, not the script execution) or a lagging, large, server. That's it. There's a couple of ways to demonstrate this, I did analysis on it. One of them is measuring the code to spawn a unit and the time the unit appears in game. The code (one line) runs in one or two milliseconds. The game takes tenths of a second though, to register the group appearing. This is also a big issue for script timing but that is irrelevant. Hence the code execution from Lua is almost nothing, but the actual C running DCS is taking a lot longer, presumably its validating the unit, the floor its going into, adding to databases, updating all the clients in game... I dunno, whatever it does that takes so long, but toi be clear thats DCS being slow, the script ran faster than is meaningfully detectable. FWIW I dont have anything additional to add to the OP except to go into detail on unit count. It's not just numbers. It's type and their combat. Especially planes, especially planes executing combat AI tasks. 30 planes in combat begins to see quite a bit of degradation and CPU use. YMMV. Recently the game engine has been much improved since March.

For lots of Coordinates use I use DCS-Scratchpad. There isnt an unmodded way of doing what you need. Scratchpad can use copy and paste. SO you can actually copy with CTRL+C from a Markpoint on the map and CTRL+V into scratchpad. You can prepopulate it before mission start and it will appear on screen in a transparency rather than a large kneeboard that requires a picture format. It's basically a hidden gem for DCS VR users and folks that dont want full featured mental apps. Or... OVR Toolkit for A steam headset

I can see complete formations over 30nm in moonlight. I can discern what is a samsite since I see the shapes. In VR it's worse due to some sort of scaling on dots they use. A screenshot looks much worse, the dots are magnified at least 4 times because I can count the pixels in VR and against a black background I get at least 4 pixels of bright white which in VR is also quite smeary and for soem reason magnified by the technology used. The only way to describe this is "wallhack" above, its a good desription! Non moonlit nights are very very dark due to lack of ambient lighting and again.. the way the lighting is handled. So this does break night flying completely. Not slightly... it makes it really unfun, certainly you couldnt do any serious multiplayer. Its a shame.

I don't think it's even possible to fix this. A warehouse in game, when set to limited stock, has no idea that it's going to get a GBU54 in 2 years time or two minutes time. That's before the many changes to GUIDs of weapons and fuel tanks that seems to periodically happen. I gave up with warehouses a long time back. The concept is what we want but the reality is that the Resource Manager System was half finished, not good enough to use because of many little niggles (like this). I don't know what to say, but I feel it will end up wishlisted, whatever is wanted. I can only see this type of issue being solved when the entire current mission table design is thrown out. Which will destroy any mission in existence anyway. The correct solution of warenhouses will involve them held locally on the DCS installation, be accessible as a saved state, as part of a saved mission, as part of a redesign of the single sortie mission design that is currently DCS.

In case anyone needs help in working out the financing of this DLC.