Stal2k

The above quote is why I was asking, in the interest of not wasting any of your time. Since you don't seem to want to answer i'll just move on. , please, and tell me what to do step by step to crash my HMD. I'll borrow what Alec supplied which is effectively the same thing in my original report, just more concise. Steps to reproduce were: -- 1. a) use high settings that demand more VRAM (textures high, terrain textures high, water high, vibility range high, heatblur low or high ...) b) raise SteamVR render resolution between 150%-200%, ingame PD setting at 1.0 at all times (somewhere is the sweetspot for your system, restart is always required to apply changes) c) having a bunch of other windows open will also help slightly raising VRAM usage (discord, simshaker ...) 2. choose a server with a big mission like TTI on Syria 3. choose any aircraft, jump to cockpit, choose next aircraft (F/A-18 or F-14 on supercarrier to have the biggest impact), jump into cockpit, check external views, switch to F10 map, switch back to cockpit, switch to F4 external view of other aircraft a couple of times. 4. repeat step 3 and at some point SteamVR should crash. The more different modules you own/can to jump into, the better... -- If those don't do it for you, congrats you are one of the lucky ones. Has anyone from ED just charged you with this issue and rested the resolution solely on your ability to reproduce? There is another thread that just popped up reporting the same issue and includes people tagged as "Closed beta tester" and "Tester." It's never been a question on if this impacts everyone, it very clearly does not. For example, If you have a 30xx series GPU, you are safe. Otherwise I wouldn't have wasted the time in making a video if anyone with VR could just crash their HMD with relatively easy to follow steps. The more you just ignore the reasonable question(s) I asked you in favor of just yelling "steps" at me, the less likely I am to want to spend more of my time refining those steps already provided to the degree they crash your personal HMD. If you are impacted by this issue, steps have been provided by myself and Alec. Since they are not working for you, I guess we can all just go home. Alternatively, help me help you. As I said, now the formal testers are starting to see this issue, so I can only assume whatever is causing it is getting worse. As an end user, I'm more inclined to you just have you go bark orders at them rather than continue to go in circles with you. Realistically, if your system was impacted it wouldn't be so hard to crash it, so even if we can refine the steps to a degree beyond what is provided, it's unlikely it will happen to you. Very genuine/serious question for you, that I'm hoping you respond to: In the interest of getting steps that work for people that are, lets say less impacted would cranking various things like Steam SS to an unreasonable amount in the interest of just replicating the crash for debugging purposes be helpful? Obviously, the pushback would be - hey nobody is going to do that, which sure. but if the only goal is getting to steps that cause it 100% of the time would this be valid?

FYI this is literally what the 80 reply thread I have is about. I'm glad people with the tag testers are starting to run into this.

Am I not allowed to speak in this thread prior to providing you steps? How about answering the questions I asked you - feel free to dial back the attitude. If the objective here is to just get me to move on and leave this issue alone based on your attitude I'm actually pretty content to do that. I do not work for you, I'm trying to help as it's impacted my enjoyment of this game as well as others. So lets baby step this, you asked what I want you to do? What I want you to do is answer my question since it seemed to really frustrate you that Alec shared the issue occurs on multiple maps/missions. So I'll ask it again, would it make sense to centralize on a single map/mission to reduce unknown variables that could be contributing, the goal being getting this issue documented to that JIRA friendly state of reproducability? Lets start there so we know when I'm trying to polish up the report for you, again I'm really sorry this is happening to you.

I do not see how many people experiencing the HMD shutdown across maps/missions preclude us from creating very explicit steps for you to recreate the circumstances both known/unknown to prompt the outcome. You said you need Exact steps and we are all clamoring to make you happy here. I personally haven't had time to dive back into this beyond replying here and expect to have some time over the weekend. You've been given steps to reproduce it from both myself and Alec, clearly, based on your experience these are not universal enough. Being that we aren't psychic we didn't know that at the time and are working to firm things up. To be absolutely, 100% crystal clear - This issue is not limited to a specific map/mission. I've had it happen across SP/MP and all maps. However, *IN THE INTEREST OF GETTING YOU WHAT YOU ASKED FOR wouldn't it make sense to centralize on a single map/mission to reduce unknown variables that could be contributing, the goal being getting this issue documented to that JIRA friendly state of reproducability? I do think the TTI Syria server/mission is a great candidate because it has the groundwork to easily prompt the crash not to be confused with the only circumstance in which it can occur.

Thanks Rob, great idea. It's the A4, that should be the only mod, I can easily remove it, or are you saying just because it had mods when I made the video it's out? Frankly, I think since we are all kind of resetting I'd rather just centralize it to a server like TTI Syria or PG like Alec is saying, the mission isn't really relevant beyond deliberately creating (I'm being very careful here with wording) "amplifying circumstance to aid in the reproduction." Does that make sense, and would it ease that particular requirement for you Pikey? I'm totally aligned with what Alec is saying, in fact, I think that is more less what I was saying in the OP minus the focus on settings. I think all of us are eyeballing the ram/vram as a likely suspect. At this point we are trying to just zero in on the cause without the luxuries Pikey outlined of a debug machine/access to the code. Virus, if you'd be willing I'd be happy to work closely with you on this as our systems/HMD closely match up. I would love if it were something stupid like DCS needs to be on your NVME drive and not just a SATA SSD or something. The situation you describe of where DCS starts chugging, if you hit F-10, F6, hell sometimes even F2 or do something crazy like swap to the F-14 on the super carrier. If your HMD doesn't black out during that, that is a great place to focus on unpacking, because mine will 10 times out of 10. When my system does that I have to treat it like a deep spin/stall and just take my hands off everything and hope it fixes itself quickly or I'm going to die :). My DCS settings are a bit more conservative then Alec's where when it was happening to him (no MSAA, low textures etc) and my SteamVR settings were dialed down from the default to 150% SS and have been for awhile. If you're willing, I think a good place to start might be a deep comparison of our systems and running software (like HOTAS stuff) and driver versions. Again, with your consent I'd be happy to move that discussion to something like a Discord PM so we aren't clogging this thread. My username is Stal2k#4371 for anyone here in the peanut gallery that wants to get involved we can set up a small group. edit: removed an extra [/Quote] and added the two final paragraphs to Virus.

Great to hear, thanks for joining in the fun here. I've also experienced the phenomenon of the high use/low fps and seemingly switching to task manager to 'threaten closing dcs' does the job and it's straightens out. It's kind of comical, strangely the "Desktop Windows Manager" process has super high GPU use that coincides with what you are talking about. I digress :) I don't think it's a WMR/reverb issue, so far I've been able to get this to happen on both an Index and Rift S. Many folks have reported on the Reverb and to summarize the rest of the thread(s) I have not seen this reported on a PiMax, and since Bignewy is the only one who actually owns a Cosmos :) (joking) he appears immune. I've noted it's a lot "harder" to make this happen on Rift S. I show in my original video this happening via switching modules but most of the folks reporting, myself included experience this when using the F-10 map on busy servers. I would like to formally apologize to everyone involved here, never did I think this would become a 7 page deep thread, I thought what I did was sufficient (in fact was even told as much) and we'd all be moving on with our lives. I'm really not much different than the 20+ other people reporting this aside from the fact I was frustrated enough that instead of just moving on from DCS, to put the time and effort into raising this issue with ED and trying to sort through it.

Listen, I may be reading 'tone' that isn't here, but from how this reads I'll attribute it to you being annoyed you were looped in and it didn't crash for you? If you did in fact read the very next line after the bullets you just listed. you would see it literally says "But this doesn't happen to me" and adds context. So I don't know what you really want me to say here? I'm sorry there was some confusion but c'mon. (excerpt from original post)“But this doesn’t happen to me / I've not had any problems” ******This seems to only happen on missions/servers where the game is stressed and moving a lot of things into and out of memory.********* This is exacerbated by..... I attached the mission I used in the video in case someone wanted to use the same one or just didn't have access to a suitable mission outlined in the context I just covered off on. It's not neccessarily part of the steps, I made it available in case whomever wanted to replicate *exactly* what I did in the video. For sure, and as we collect data in terms of commonalities amongst those sharing, which we have already learned a lot if you read the whole thread (I did, not asking you to). The thought process is after ___ amount of people report the same thing what is the number before the assumption is no longer we are idiots that messed up our computers in the exact same way at roughly the same time? Being as it's clearly hard to narrow down an issue like this, that is the purpose of a thread like this. I agree with you it can be a lot of noise, but just getting an assessment of how many people are impacted is important. Believe it or not, I did think it was something I caused myself for a long time, even considered an RMA. Even without an explicit path to get the result 100% of the time on an issue like this, you can't just wipe your ass with user accounts of vary value. If a developer sees this and knows they made some large change to the areas, like (unless I'm totally making this up) the way the F10 map and memory was managed ~2 months or so ago; it would at least be beyond pure worthless conjecture that hey, the issue may have been introduced here and maybe we should roll this back until we can figure it out? I will do my best to clean up the original post based on what we've already learned, and if you think it'd be helpful I'll add in the steps Alec is showing above in regards to VRAM and the associated spikes. From the first post, the video inlined should answer does it work immediately or straight away? (I can do this on purposes fairly quick, it took ~2 minutes in original video) Do you have to go between several cockpits? How Many? Specific Ones? (Did it with just the hornet and tomcat, it depends but cockpit/module switching excaserbates the issue) Do you have to fly from a certain slot in a certain place? (no) Beyond the video... Q:Whats going on in the mission? A: It's just starting up, so some random CAPs are spawning, however the issue isn't exclusive to that mission I can do the same thing on a different map or public server like TTI Q: Does the problem happen all the time? A: Yeah, pretty much if I load that mission and replicate the actions I take, it will happen. It might take an extra F-10 vs just spawning ito an F-14 slot but yeah. That is as precise as I could make it, and at the time hoped it would suffice. On Syria/PG, pretty much will happen 90% of the time if I play longer than 5 minutes. Switching modules or hitting F10 is basically rolling a dice of diminishing returns on if it will crash or not. Personally, like many of the others in this thread have developed a "feel" for avoiding things likely to cause the crash. It's not as bad on Caucasus, for example I spent several hours in a lower key Krasnodar Ground Strike mission and didn't have the issues. I don't want to get ahead of myself, but I'm actually able to somewhat consisentantly cause the crash by opening larger missions in the mission editor consecutively. Rolling all this back, I am an end user with a problem that a (seemingly) non insignificant amount of people are experiencing. I'm doing my absolute best to be as thorough and detailed as possible, and in fact did provide in some capacity many of the things you're asking for. As I said, I'll try to clean it up and get even more definitive actions as you outlined I don't know what your affilliation is with ED, I'm assuming by your tone and the "I was asked to help with this" comment you are a prominent community (moose dev?) member and tester of some capacity? I've also spent a considerable amount of time not only getting to the point where I could make it happen on *my* system at will, but getting folks to report in this thread to hopefully validate that it's not just a me thing. That being said, I'll ask again if you would like to work together on this would it make sense to organize a more streamlined way to communicate, i.e. discord? I'm pretty sure I can figure out who you are on the ED discord and can just send you a PM, my name is the same here and there. I'll review your video and see if I see any major things that are allowing you to inadvertantly sidestep the issue. To your point, I'm sure SteamVR or WMR or whatever could be much better, so to make sure I understand - let me phrase the question a different way. If DCS was causing windows to blue screen, that would be Windows crashing not DCS right? Does that mean we just say windows is dogpoo and shrug our shoulders and move on? Or would it make sense to maybe look at engineering around the issue to prevent users that aren't obligated to be experts from running face first into it? A point of clarity on terminology here, to make sure I'm saying the right thing and understand what you mean. When I say overlay, I mean when you hit the system button on the controller or HMD to bring up the SteamVR "overlay" or the Oculus dashboard etc. There really isn't a way to not do that so I assume you mean an overlay like FpsVR technically is, or OVR toolkit or something 3rd party along those lines - if so I'm totally aligned with you there and hope I didn't unintentionally seem like I was making that case. However, If we are just going to leave the blame at Steam/WMR/Oculus because their overlay crashes, I'd argue there is some onus on the developer by supporting the platform(s) to make a reasonable effort to work around an issue like this which is only happening to DCS.

Great, what is the best way to get in touch - discord? So you are experiencing the crash, just less frequent. I'm aligned with you on the a lot of what your saying, this seemed to start when they made changes to the way F-10 was handled a few months back. I'm totally with you as I have been from the early pages in that I don't want to turn this into a performance or tuning excercise as that isn't helpful. Ok, when you are doing this are are you using your own mission, the one I provided, a multiplayer server etc? If you just load up a blank mission with all the planes it's unlikely to happen because there needs to be other stuff going on. Use a DCS liberation Syria mission or TTI Syria map if you need something easily accessible that will have the right other conditions required. Also if you could share or PM your config I'll replicate it as close as possible to ease effort on your end.

Thanks Alec, that goes in line (I think) with my initial speculation this has to do with rapid memory I/O or I guess based on your testing overstuffing. Bignewy, do you have any update on this in terms of the testers? Is this still considered closed because you can't replicate or is information like Alec is supplying helpful and the effort is ongoing? My assumption is that even as this thread continues to grow the official status on this is "Unable to replicate," is that accurate?

Yep I went back and forth between release and beta just to test. The crash still happens with just Oculus software, not Oculus via SteamVR which is a strong indicator it ain't SteamVR. I don't have a WMR headset so I can only go off what others have said in so much that it also bricks the WMR software. I will say that anecdotally it's a bit more difficult to do this intentionally with just the Oculus software running.

Initially, I thought the same thing, but it happens with the Oculus software as well (tested myself) and according to others reports WMR. Do you have anything you could share on the issue being central to SteamVR, i.e. something from the SteamVR bug forum? In terms of getting this fixed, I guess all we can do is continue to pile on here until it becomes even more overwhelming. You can see from a few posts up the last word is they can't reproduce, my hope is BN answers some of the questions I posed in regards to helping them reproduce this issue or what else we could possibly do to help them narrow it down. So far the big common factors are Issue is common during heavy memory I/O, i.e. F10 map or external views/module switching This popped up around the same time Syria launched, though not just a Syria issue Folks with more than 11gb VRAM seem unimpacted Happens to Steam/WMR/Rift HMDs I personally intend to continue to follow up on this until I'm either told they won't fix it and we all need 3090s now for MP VR or they share some meaningful progress on getting this resolved.

I don't think that currently, I said initially. However, you only said YOU could not reproduce it, and at that point said you were bringing in a tester. There was no follow up since then, so I'm unclear on your progress in reproducing the issue. If I'm to understand based on this response you and the tester you've enlisted were unable to reproduce it then the next step would be to communicate that in this thread. The last note from you on this was you were getting a tester to help, then nothing so how would we know you haven't been able to reproduce? As you've seen, roughly ~24 people or so between here and the hoggit thread are reporting it, so if I were you I'd ask for one of them to help in a more direct manner - much like what was done in the past with regards to the "50% vr performance" troubleshooting. That to me would say you were taking it seriously. Also, not pushing a stable update with an issue like this present would tell me you were taking it seriously. I'm not trying to be overly harsh here, but since you asked how to fix and state reproduction being the biggest issue; then the next steps would be to outline an action plan on how you either 1) plan to scale out testing/hardware configuration of the testers TO REPRODUCE or 2) steps or even intent to look into a possible causes i.e. relation to the recent overhaul of how the F10 menu/memory is handled from about two months ago and most importantly 3) an idea of when you or someone would give a response on the results of those actions. 9/13 I reached out to you privately about this and supplied a mission file to help encourage this crash as a follow up from someone elses reddit thread on the problem, you said you'd take a look. 9/30 I checked back in about this via discord on 9/30 asking if you were tracking this internally yet, and you responded "if you have the steps to make it crash please post, I use stream vr everyday and not seen an issue myself" 10/2 I posted this thread and give you a nudge about it, you again responded that YOU personally couldn't reproduce this and suggested the typical repair/unmod steps. Several others piled into the this thread, and the one I made on hoggit saying they were having the same issue, you said you were getting a tester to look at it and that was it until now So why would I think that you all aren't taking this seriously? Your initial response(s) to me from 9/13 up through page one of this thread indicates to me that despite spurious reports about this issue from other people you were still treating it like an individual user problem which is understandable. After what I would consider an undeniable amount of folks began substantiating the issue beyond you saying you would have someone else look at it, it's been radio silence. For me personally, I've been doing this w/ you since mid September. I understand you must have a lot of things reported, and you can't be expected to follow up with everything but after being told you'd look into it without any follow up 3x and doing what you asked me to do it's frustrating to hear basically the same thing you told me on the 9/13 in terms of some variant of "someone will look into this." without any follow up - even if it's bad news it just seems like the solution is currently to hope it just goes away/fixes itself.

While I'm certainly a fan of letting no good crisis go to waste it does sound a bit different. For VR. That thread describes a specific consequence of zooming into a bunch of units in F10. For this thread, it's not zooming in, merely opening F10 will prompt it. DCS doesn't actually crash per say, just your HMD/overlay.

To be fair, I kind of get where @CobaltUK was coming from. I know you had the best intentions but as you can kind of see from even this thread, it can be a challenge to get ED to start taking something seriously. I don't blame them either, as they have a pretty full plate with all the other issues. It takes a good deal of work to push past the point of it just being assuming it's something the end-user is causing themselves through either mods or some other bastardization of what you'd call reasonable use of the software. That is the main reason why, despite you trying to offer "solutions," for me anyway, was missing the mark. It wasn't about solving my problem, it was about solving the problem for me and everyone else. That needs to happen on the ED side, not my personal configuration. Crashing a VR HMD in such a severe manner some people are (erroneously) RMA'ing their devices isn't even close to being accepting of, or tweaking settings to accomadate poor (read: unoptimized) hardware utilization. Believe it or not, this isn't the first time I've had to report in great detail a VR issue that others impacted were either unable or failed to articulate in a way that wasn't dismissed. One of the toughest parts of crossing that hump is getting buy-in from ED that it isn't just a "you problem." I'll admit there was a lot less pushback the last time, but it was also easier to reproduce. I just got home and was actually going to make a note about asking BIGNEWY for a status update on this and suggest maybe not pushing a stable update with a known bug of this degree - but that ship kind of sailed :)

So Bignewy, between this thread and the one I started on hoggit we are now in the double digits (13 as of this post) of people directly reporting this issue. Are we yet at the point where someone will (seriously) look at this, or what further action/proof is required? I would hope we are at least past the point of considering this just a "me" problem. **edit: Inadvertantly ended up chatting to BN on discord about this and would like to tone down my statement here. It's been acknowledge and now it seems like the next step is for ED to replicate on their end**

FWIW I posted a link to this thread on hoggit and within 3 hours, there are already 4 people saying this is happening to them. One guy even RMA'd his headset, this might be more widespread then is being reported, because frankly it doesn't look like a DCS issue at first.

Thanks BN, yes I agree but as I'm sure you're aware most folks with 20xx gpus are heavily CPU bound. My GPU usage is typically around 60%, in fact upgrading to the 2080ti required MORE SS just to slow down the GPU enough to be able to dance comfortably with the CPU frame times. This is what I was trying to avoid in making this about my settings, I would totally understand if I was the only person having this problem - but I'm not and as more and more people are replying you can see the commonalities (timing, and F10 usage/memory stressing) Thank you, that is really the only goal here is to get some attention put onto the issue. If they are unable to reproduce I'm happy to try to find out exactly which OB introduced the issue, obviously I'd rather not spend the time if you guys can do it internally but it's been really hurting the experience lately.

Listen, I know you are trying to help but the issue is not the DCS doesn't run well, or that SS taxes hardware. Those things were true 3 patches ago and you could still play this game without getting booted to the desktop from a random SteamVR fail that was introduced in a semi-recent OB build. Everything you said is true with regards to the memory management and whatnot, but at no point is crashing the VR overlay part of what we've kind of collectively accepted as 'unoptimized.'There was a change to the way the F10 menu was handeling things a few patches back and my intent is to highlight that there might be some lingering issues impacting VR users that are really frustrating. FWIW I can also do this without ANY SS on my other system, and yes I think between the myriad of other people reporting the issue and the feedback in this thread we can all at least sort of agree it's centered around 1) a recent OB patch 2) memory usage 3) the F10 menu.

I mean sure, but what will that accomplish? That kind of lends some credence to my theory of this being memory-related. The intent of my post was to 1) illustrate this issue and 2) get them to fix it. If someone on the dev team (or you are on the dev team) would benefit from doing that I'd be happy to. I'm hesitant to really get lost in the settings as then this becomes a conversation about my settings and not the issue of VR HMDs shutting down. My settings haven't really changed in ~5 months or so on my main rig and are very conservative on my 2nd system. I'm not using any in-game PD and about 150% SS total via steam. My DCS settings are effectively in line with the latest VR best practice video, no MSAA, low anisotropic, low/flat shadows, low terrain texture etc. Even if they were cranked, it's not a valid reason for the game to crash like this during moments of intense memory I/O.

This is very similar to what happens to both myself and another guy I fly with a lot. That is why I'm speculating it has to do with moving a lot of data into and out of the RAM when it is at, or very nearly full. That would make sense with spending a lot of time in a mission, the F10 map is very much a kiss of death for us (and this bug) as well.

BIGNEWY, I know its a bit of a wall of text but you can see I've tried these things under the "Things I've tried section." It happens on two different computers with effectively independent hardware. When I was trying to get it to stop previously I've removed all mods. I'm happy to do it again and video if that is the only way to get someone to look into this. Clearly, from this thread and the others I linked it's not just me. As far as running a 2nd VR mirror goes, no I do not, I simply did that for the recording to let illustrate what was going on in the HMD vs the desktop where you can actually see the crash. To everyone else, yes it's very inconsistent for me as well and I've gotten decent at "playing around" the issue in terms of not doing things that will piss the game off. As I said, I went for roughly a two week spell where I was just running Raven One and very light missions and it never crashed. I just also figured out how to kind of force it to happen which made the video an unedited 4 minutes instead of a fairly lengthy capture just waiting for it to happen on it's own.

This post is 1) a description of an issue that has been plaguing DCS VR for at least two patches now. 2) Overview of how to replicate for ED 3) link to the mission file used in the video 4) Things I’ve already tried Video Link: The left side is the direct feed from my HMD, the right is a desktop capture to see what the crash looks like. In the video, after the crash the (left) HMD view seems to just freeze. That is just how its captured, it's very much turning off/going black when the fail message pops up Timestamps: 2:00 is where I get into the game and fly around for just a bit. 3:18 I start intentionally making it mad 4:10 Crash is called out, HMD goes blank when the error pops up (just freezes in video) Issue Description DCS is seemingly causing VR HMDs to turn off, leaving DCS running but giving a fail in the VR client (steam) or just outright closing (Oculus). This has happened to me on virtually every map at this point, I used Syria because it’s fairly heavy and I can trigger the issue on it like clockwork. My speculation is this has to do with when a lot of things are moving into/out of RAM. This is more common with SteamVR, but I’ve been able to replicate this with the Rift S as well. How to replicate Leading with the assumption made about RAM I/O, using the Syria map (although PG would work as well), and swapping between modules/F-10 will usually cause the crash as shown in the video. One of my friends put it perfectly when he says “There is a 60% chance if I hit F-10 on Syria that my VR will shut off.” The most egregious example of this was going quickly from the Syria map itself, quitting and opening the mission editor for a Nevada map caused the issue. In summary: • 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) “But this doesn’t happen to me / I've not had any problems” This seems to only happen on missions/servers where the game is stressed and moving a lot of things into and out of memory. This is exacerbated by 1) using the F10 map 2) Switching modules, especially to the F-14 + Super Carrier and 3) Bringing up VR overlay (Steam). Chances are very good if you are not using multiplayer, or even missions with a lot of memory I/O this will not happen to you. I actually thought I'd fixed the issue when I went for about two weeks with only doing single player and lightweight 1v1 instant actions. “This is probably Steam, your HMD, your CPU etc., not DCS” Believe me, I thought so too. In fact, I suspect a LOT of people that are impacted by this are making that assumption. Between the small group of people, I usually fly with, some random people’s comments in multiplayer chat and the FoH tournament voice chat, this issue is not uncommon and most folks think it is their HMD/CPU/Steam so they are not reporting it. So how do I know this is DCS? I don’t, but if I combine all the steps I’ve done below to troubleshoot with uptick of similar issues being reported by others in the linked threads along with the demonstrated replication should hopefully at least present a case for ED to look into it. Things I’ve tried already Look, I get it you have to do all the “make sure it’s plugged in” steps, hopefully between the video, steps I’ve outlined below and the threads showing multiple other people having this issue we can quickly move past the basics. Disclaimer: My CPU/GPU/RAM are not overclocked, nor is there any notable heat issues presenting on either system. • Have tried this on two different computers • Happens on both Oculus Rift S and Index, albeit the Rift S it’s less frequent • Have tried different USB/Display ports • Closing SRS / running a virgin (repaired, no mods) instance of DCS • Drivers/Windows/DCS all running latest versions, this problem has existed through at least 2x updates of both drivers and DCS. Switching Steam between stable/OB doesn’t matter, as mentioned this will happen on the Rift S as well (running native Oculus SDK) Someone is going to inevitably say you need to update _______, turn off ______, it’s your _______. Ask yourself this before offering such advice, “Would a different HMD and/or test system invalidate my suggestion?” If the answer is yes, consider it invalidated :) Reference threads (People having the same problem): https://forums.eagle.ru/showthread.php?p=4472903 https://forums.eagle.ru/showthread.php?t=231473 https://forums.eagle.ru/showthread.php?t=267004&highlight=crash Attachments: Mission used in the video Dxdiag.txt file DCS.log file, had to rar it because uploader wouldn't take it due to 500kb limit System 1: 2080ti / 32gb ram / 9900k System 2 : 1080 / 16gb ram / 7700k Syria Dynamic Sandbox v.10b.miz DxDiag.txt dcs-log.rar

I'm having this issue, Valve Index as well using latest NVidia drivers. The error code is -203, does that track what others are seeing? RedeyeStorm are you using latest nvidia drivers? Maybe a rollback could help. I will say it only seems to happen on missions that are pretty heavy. For example a mission generated by the DCS liberation campaign will do it. We loaded up a fairly dense one and I crashed maybe 4x pretty frequently until we cleared some of the units.

They know about it, I reported it like ~4 days ago and the thread has a [REPORTED] marking. I spoke with one of the ED guys directly prior to reporting it so hopefully, that qualifies. The good news is this is getting a ton of attention as every thread that pops up and is related is a few pages deep. It's strange it just happens to the Index though, I plugged in a Rift S just to see and it wasn't a factor. Plugged the index back in and it's here. The whole MSAA off --> on thing did work but I don't think that is an actual fix, more like a workaround.

Could be then, it's not impacting the Cosmos though right? I guess that torpedos both my theories that it's lighthouse/motion smoothing related. The PiMax uses it's own 1st party motion smoothing ya? I know WMR headsets do for the most part unless the Odyssey is different.