Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Stal2k

  1. I'm also having this issue in both the training and also Rudel-CHW's training mission. I was about to try making my own just to see if it's something weird or just user error.... I don't have track files because mine are disabled, but I'll attach several tacviews showing the same thing OP described. I tried both CC and EFF modes as well, I'm NOT sure if this impacts more than just a DIR launch, I didn't try the others but kind of gave up assuming something was broken. I looked at the quick guide, Chucks guide and at least one non Grim Reaper video on it and can't figure out what I was doing wrong. I guess if someone else's reporting it, it might not just be me. Setups DIR mode TP used as briefed CC/EFF modes both tried Variety of sea/skim/popup/skim options tried, none seem to work. JF-17 Anti ship missile.zip
  2. Listen, that little hiccup aside I think for what you've done it's truly a master class in DCS mission/campaign making and what is possible. I can say that it's the first campaign I've ever actually finished and I've bought 90% of them. I either move on because they are too boring or are broken. When I wrote that post I was just fresh off a successful run and maybe a little extra agitated when I realized what it was causing me to fail I only experienced two other times a mission 'broke' and one was really on me for not following directions (killing the right ground targets without clearance from the seal team) and the other time was the CAP mission w/ the strike from Iran. For whatever reason, the two escorts fired and immediately RTB'd (in the Tacview) and as a result we never actually killed them so I think the mission got hung. I just reset CAP and ultimately RTB'd once fuel required. I watched Redkite's playthrough to see what was supposed to happen and ya, all events after that initial onslaught never happened. That all being said, it as really an incredible experience, I loved how challenging it was and how you really had to know the Hornet to get the job done. I assume the other two breakages I mentioned above to be very one off (one really being user error), but if you'd like any more detail I'm happy to provide Tacviews (I have tracks turned off).
  3. Hi, Mission 14 was incredibly frustrating and I spent maybe 4-5 hours reflying it from what I think is really avoidable things that could have went in the designer notes. I shouldn't fail the mission because I followed instructions explicitly, or at least why I think I failed. I got the thunderstorm call 3x in a row and couldn't figure it out, I thought maybe it was because I went to the radar SMS page, maybe because I turned my FLIR on, DL on etc. I never touched the radar during startup even to put it in standby (after 1st run) just to be safe. What I think the problem was is that, as briefed I'd get into formation over land between WP1 and 2 ahead of and to the left of Tron 52 mirroring Sledge 21 on the other side. However if you stay in formation you will fail based on altitude (I assume) when hitting WP 3. Looking at the Tacview those flights are well above 1000ft when feet wet (Tron 2kft Sledge 2.8kft AGL). So basically after 3 tries I just aggressively dove after clearing the mountains to be at 900ft AGL when I hit wp 3, Obviously this puts you way out of position regarding the formation. That seemed to do it as I really did nothing different other than that the other few times. If the mission is scripted in such a way that you fail if you above 1000ft AGL when hitting WP 3, it should be noted in the designers notes that the AI will not meet this criteria and flying in formation as briefed with Tron will also cause you to not hit the mark. I get that making you fly the entire ~70+ mile leg without telling you failed is part of the immersion and staying true to the book, but I think something should be done to account for the 'simism' of the AI not meeting the outlined criteria and respecting people's time. Adding a note would be bare minimum, moving the waypoint a bit further out would be another thing, or a debug style message that at least alerts you what happened, i.e. busted altitude. For reference I'm citing this part from the briefing: "After the push, we will get in formation over the land, flying NOE. Once we clear the mountains and enter the Persian Gulf, we will descend below 1000 feet AGL. Again, let me stress how important it is that we are not detected - therefore each flight is required to stay below 5000 MSL over land and 1000 feet above water at all times on the way to waypoint 4. Once we pass waypoint 3 we can energise our radars. I will give you a sign by dumping some fuel - the streak should be clearly visible in your NVGs. With the help of ground radars, we will avoid any maritime traffic along our way." Same thing in the kneeboard notes, it says "follow Tron 51: full EMCON" & "Stay below 1000ft between wp3 and 4," you can't do both, not to mention in the briefing it says to stay AHEAD of and to the left of Tron. Hopefully this isn't overly nitpicky, but I feel like these details are very important given the requirements of the mission. It should be made clear to the player where they may need to diverge from what is being said for gameplay purposes. Other things that are minor annoyances but could be cleared up in a patch Make NVGs default loadout, the briefing references NVGs and they are certainly a good thing to have, a first time player (of the mission) may not know he has to switch those out w/ Ground crew when typically in this campaign your jet is pre-configured rather nicely Swap default A2G pod to ATFLIR, the brief references ATFLIR but the base loadout is LITENING
  4. I am getting the same, the machine may just be offline. It's probably not an issue on our end and I'd check back in a day or two. FWIW it's been like that for a few days now and I'm sure whatever machine (if it's local) is server the files probably isn't the daily driver
  5. No I didn't notice any exploding of the Wingman, the only exploding was the F-5 on the ramp (video timestamp is 1:12:03). Reviewing the tacview, he didn't 'switch himself' like he usually does in the past with a new unit though, maybe related? Something else I noticed that may or may not be related is during the practice missions with airstarts, a few times I'd get a KIO call when there is still very much an alive hostile. To be fair, it does seem like they disengage and it doesn't seem like a bug (maybe hard deck violation by ai?) but maybe that contributed to getting wires crossed with Bozo_'s experience. Since hammer isn't despawning he could have exploded for any number of reasons like lingering damage, an unseen missile still in the air etc. To explore a bit further on the whole kiss off thing before the break. I am no procedural expert, but I understood the kiss off for an overhead to occur just before lead pulls into the break 1st, is that accurate? If so I get the workaround is either letting your wingman go first and forgetting about him or just doing it much earlier. The thing is, for folks that are trying to do it sort of how you'd do it for a carrier break (or at least how I understand it to work) your wing gets REALLY close to hitting you, in fact he would have hit me if I didn't move aggressively on an earlier hop. So I guess the question really is, in the interest of working around DCS would it 1) be better if your wing didn't slide to your left to avoid possible collision or 2) add a text disclaimer to the prompt to tell the player to perform the kiss off much earlier, 3) I'm doing it wrong and need to adjust my approach no pun intended. I attached the Tacview for you if you want to see the behavior after the engagement, wing despawning on landing or the parking incident (although the video shows the result better). please ignore my Syrian lead turn w/ the wildcard haha. Tacview-20210204-235538-DCS-Zone 5 - 05.zip.acmi
  6. Had some issues myself with Hop 5. Bozo_, I think the targeting has to do with them being so low, he isn't actually picking them up on radar. You can work around this by either have him aim the radar lower, or in the STT menu select lock specific target, and choosing the D/L contacts should result in an STT. Not ideal, but I think that is more Jester than the campaign. Bugs/Problems 1. Next flight almost runs into you: On the egress, similar to on hop 3 there is a 2-ship flight inbound to the range that comes dangerously close to you if you are following the waypoints (between IP->WP2). 2. This is on all missions thus far where you are flight lead, when you kiss off your wingman to start your break he immediately cuts hard into you instead of waiting ~20 seconds or so before beginning his break turn. If working around DCS is hard there, would recommend keeping him on the right side and just let the player know you have to let your wing enter the break first. 2a. Wingman almost seemingly slammed into the mountain on his own, but that might just be DCS being DCS, at least looking at the tacview it's unclear if he despawned on... purpose or hit the mountain. 3. Super nitpicky but on the outro Bio talks about getting the ID before shooting sparrow etc. During the briefing he says all groups are hostile, so no ID should be required. 4. After parking my plane, the aggressor (agrback in tacview) proceeds to ram into the F-5 static object in front of me occupying the space I assume he wanted. Here is a video, sorry my sound didn't record but you don't really need it to validate.
  7. Low impact but I wanted to share issues encountered in this mission, should be easy enough to validate and fix without a trackfile. This is a pretty fun instant action, but could use a polish pass :) Loadout: you spawn with 9 aim-120cs, assuming this is meant to be 10 as 9 isn't going for realism (could be wrong), this creates an asymmetrical loadout from the start Mig 29/E2: Recommend either moving the E2 or making it invisible, when the Mig-29 spawns in it makes a beeline for and shoots down the AWACS, again assuming this isn't intended as the mission is called gauntlet, not HVAACAP. This also puts you in a position to try to 'run down' the Mig for ~50nm rear aspect until it kills the E2 When you roll from the Su-27 to the mig-31 phase, the mission immediately gives you credit as if you won even though the Mig-31 just spawned - likely just a flag or condition set incorrectly
  8. Alright, so I haven't had any crashes and played a good bit over the weekend. I will say that the F-14 in Syria, at least for the mission we were playing (liberation) was basically unplayable. I got into an F-18 and also an A-10 and everything was fine. The Tomcat, gives me like 5-13fps with that Desktop Window Manager process going crazy. So ya, I'm fairly confident, at least for me that the GPU scheduling feature and DCS = poopstorm for SteamVR. Now it's just back to regular hit or miss VR performance.
  9. I did two things which I believe had an impact. 1) I've only had one crash since I disabled the GPU Scheduling which is a huge improvement 2) Disabled the let windows adjust scaling to improve blurry text. At least anecdotally it seems this cut down runaway GPU usage with the Desktop Window Manager process which was another big problem. Since the patch, I've only flown on NTTR, actually the Viggen Red Flag campaign which is fairly busy and it ran decently. I should do a liberation mission with some people this weekend and will report if there are any major problems. I will also say that unsurprisingly the additional 32gb of ram I added (64gb total) didn't really change much other than being able to comfortably leave Chrome open while I play.
  10. OK, I've been having good luck. While I'm not ready to say it's for sure a fix it's good enough that I thought I'd add it here to let some others having the issue test along with me. In windows, hit your Windows Graphic Settings (Windows key an type Graphics as a shortcut), turn off "Hardware-accelerated GPU scheduling" and restart. I've not had a crash since I've done this, although performance seems notably worse. I've also ordered another 32gb of ram (giving me 64gb total) and will try it with and without the GPU scheduling option. If this turns out to be the root cause, my hope is this won't turn into a cop-out for ED to drop the issue and call it "fixed" because the GPU scheduler is still a feature of Windows that will impact users who don't know they need to go in there and turn off something that is by all accounts an improvement in latency and performance. If someone keeping up w/ this like Divinee can verify it stops crashes or Pikey is feeling froggy and wants to turn his ON and see if he can get crashes by all means. That should help w/ duplication if this is in fact the problem.
  11. This happens to me as well, I kind of just chalk it up as DCS being DCS. Out of curiosity, when you switch to task manager do you have the GPU usage column enabled? If so, try organizing by that and see if Desktop Windows Manager is really high GPU usage. It's strange, but ya seemingly switching to task manager will clear it up after 5-30 seconds.
  12. Sure, in the interest of ruling things out, what are your thoughts on this. Since I couldn't get an older OB from the server, I DO have an older copy on my laptop still that is (well before the patches that caused it to act up for me). Would copying that to this computer and effectively running the same sort of steps (would have to be on PG) and in essence NOT getting the crash prove/rule out anything? To me that would show it's certainly code related in the sense of aggravating the driver/hw components your're speaking of, my suspicions are patches .52196 or .50726. I can be 90% certain it didn't happen prior to .version .49798 and was 100% present for Syria, that is a time span of about 2.5 months or so. Both the versions I listed as suspect have changelogs containing items that are at least related to some of the things we are seeing like F10 maps and 'improved startup times.' Aside from that, I will try less than 1.0 PD settings in DCS. I already run w/ the low textures and MSAA off, I guess really the only thing you suggested I don't currently do is the PD. The frequency of the issue is very map dependant, I played for a few hours straight on Caucasus in a pretty heavy mission and aside from just, generally not great performance it didn't actually crash. If I load up Syria, it's just a matter of time, I suspect Channel is the same but I've rarely used that map although I do own it. I might just copy that older DCS version over out of morbid curiosity.
  13. It's good (sort of) to see this as it's seemed like it's been a bit of just me and Pikey trying to figure this out lately and naturally turning the focus back to something specific I'm doing. It's not good in the sense you are having a problem, but good in the sense of validating I'm not crazy and there is in fact an issue that is hitting some people and not others. Of course, if you'd be so kind as to add a bit more detail it'd be helpful. Even if you kind of scroll through the last few pages and see what is being asked for in terms of, your system specs, VR HMD etc. There very well may be some sort of commonality between all of us nobody has noticed yet but as of right now it seems to just be in-game behavior. Can you verify the crash happens as I've laid it out, with 1) the black HMD and 2) DCS continuing to run 3) VR client fail, be it Steam, WMR, or in the case of Oculus it just shuts down.
  14. 1) It's a version of The Round Table by Mith.ar https://www.digitalcombatsimulator.c...files/3311949/. I modified it to suit my needs including the transplanted BFM arena. 2) This has been going on since June, so I've used every version since then and even tried flipping back to stable 3) My pd in DCS is 1.0, I never change it inside DCS 4) Like I said, the vanilla copy with the MSAA and 200% SS we were using for testing makes it pretty rough. There were probably instances during the videos I could have also avoided the crash by calming down the cycling, but since we were trying to crash it I didn't. I don't disagree with you that there is something wrong, but I just don't see this anywhere else when I use the PC. I thought about temperature, I thought about bad SSDs I even thought about something wrong with my GPU. These issues would crop up in other games, and for the SSD I used a different drive for the vanilla DCS I installed. Same thing with my ram, if I had a bad module it would crash other stuff that I do. So the first thing I do is switch back to my main install that has shader mods that take off some of the weight. Secondly, I just avoid the Syria map as it's easily the worst. Oddly enough though if I just kind of 'take my medicine' and eat a crash or two I can stay in the game awhile. Otherwise I've just kind of learned how to be careful when doing things that would cause it to crash. I can play on the Caucasus with a pretty high success rate and haven't really tried the Persian Gulf recently but it's somewhere in between NTTR and Syria. For giggles I also tried the shared parser, even though I know that also #triggers BigNewy :) I hadn't used it in awhile. Still crashed, I also saw someone say something about Malwarebytes and DCS not liking each other, I do use that software so I got rid of it temporarily. Unfortunately same thing. There is a pretty wide spectrum of how DCS runs in VR just based on the HMD you are using, I do think the people with Reverbs and Rifts tend to have a better time than those of us with lighthouse based hmds like the Index and Vive. I *can* get DCS to run in what I'd call a semi-decent state in certain circumstances for a while, but since it's heavily CPU bound in VR my GPU is underutilized and going to 32gb of ram was a big performance gain. I actually had another fairly lengthy thread about what you actually get performance-wise in VR, but that is a whole other therapy session. I guess in a way you are sort of winding around to the reason I made this thread in the first place. It's super frustrating and its to the point now where I'd gladly just get a damn 3090 or whatever to avoid it if there were any around for something close to retail. Best option would be for ED to fix this, like I have stated multiple times it's not just me while I totally realize how much it looks like it's localized to my system. To your point, it'd be great if one of these other people that +1'd would hop in and do some testing. Unfortunately, the only one of the guys I fly with regularly that had the same issue upgraded his GPU so he no longer has it. Maybe those two testers are doing stuff behind the scenes :joystick:
  15. I think I'm doing a poor job, probably because I'm over-explaining. I would define powered blackness as the state of just loading into a game or something where the screen is black but still backlit. That isn't what is happening, to either the Rift S or the Index. For me, the screen turns OFF, totally off like in the state it's in when you pull it out of the box. The only indication there is still power to the device is the lights on the front. You have to effectively power cycle it to get it to display again. Same, I'm using that plugin. The one minor thing you aren't seeing in the videos because the capture freezes effectively w/ the headset is the disconnection notice in the DCS mirror right after. It's like a TRACKIR removed note, basically the same as if you plug/unplug a USB hotas or something during gameplay. I get it, I don't want to repeat myself because I addressed that in a bullet in the last post. I completely understand that, that is what it looks like but I just point to the quantity of other folks that not only Have vr --> "qualify" for the crash --> play MP or denser missions that cause the crash --> check the forums. Getting 20+ folks including testers that filter through that fallout tells me if it is hardware-related, it's something that needs to be developed around. Because I'm currently the only one doing all these tests, it's easy to get tunnel vision on my specific system. Going back to the original post, I was able to get this to happen on a totally different computer (same HMDs though) and I do play a myriad of other VR games, this doesn't happen EVER on anything else. Amount of success: I never failed to reproduce, it was more a question of when then if. FWIW because of the easier time I had reproducing on the vanilla install with the pumped up (200%) SS an 2xMSAA it still really seems like there is a "line" in terms of what you can get away with related to memory. Variations/revised steps/version: You can reference the notes for each package, I would summarize as bouncing between the more formal steps you established and just regular gameplay. In terms of revised steps, I tried to get something done w/ using the mission editor and loading two different maps + unit lists prior to loading the test mission in the interest of creating the instability needed to cause the crash. Aside from package 3, I didn't really have success in this regard to the degree I'd feel comfortable documenting the steps. So in a nutshell, I think what you have is fine and it never failed to work, it would just take longer then if I just bounced between two slots (SC and airbase) and used aggressive F2/F10 use to cause instability. I like that with your steps there is a noticeable progression to getting to that instability. The version of your original mission was left untouched, I updated mine (mission 2) to remove the A4, I used that for normal gameplay. Is it unplayable?: This is the real question. I can sort of answer it by looking at how much of my free time I've spent to get to this point :). It does happen, almost every time. You do learn to work around it, i.e. delaying the onset. This is very much a "feel" you develop very similar to learning how not to rip off the wings of an F-14 or set the C-101EB engine on fire. This is a combination of two behaviors, 1) avoiding using F-10 or really anything that involves switching the screen drastically when the performance is anything but smooth (it rarely is). 2) recognizing the slowdown and, for whatever reason, alt tabbing to the task manager and just letting it sit there will smooth it out (yes, I realize that sounds stupid). Doing those things will at least delay it, sometimes it comes out of nowhere, which I think you can see in package 8 but usually you will see/feel it coming. So in summary, the game isn't unplayable in the sense of if I modified my behavior to only do small scenarios or really well-made campaigns like Raven one, it's unlikely I'll see or run into this. However, if I fly with friends or participate in one of the popular multiplayer servers that run on PG/Syria I'm very much on borrowed time. I know that is a lot and very anecdotal, but if you comb through this thread and the reddit thread of people that are providing some detail, you will see a lot of commonality with the 1) HMD going black, 2) what it feels like in terms of when it's about to happen (F-10 menu being a biggy) and 3) roughly the time this became prominent again, which is sometime around ~2 months ago and *after* the launch of the SC. Like you said, I did a ton of tests and can only offer so much more value as an individual. One thing I could and would be willing to do since we can force the crash so quickly is to figure out EXACTLY which open beta patch introduced this for me personally. Based on Rob's account and a few other random posts I could find, this has happened to some degree before. I ballpark this as a patch after the SC and before Syria. So what I might do is ask you to either transplant your mission or let me use my mission 3 as the tester and use PG as the "home." Using our steps and see if it crashes, continue bumping the version until it does. edit: I narrowed the list of versions this likely occurred but it doesn't seem like I'm able to get them anymore from the server using Skatezilla's updater. I'll look into if there is another way to get them but for whatever reason, it won't even let me grab something as recent as 7/15 ( Without being able to test my best guess is it occurred in between builds (6/02/20) and (08/18/20). There are changelog entries in builds .50726 & .52196 that would align with what we are seeing memory wise. Thanks for your time.
  16. Alright I ran several more tests and crashes. Unfortunately, I’m at a 100% success rate here. There were times I tried some of the things mentioned before, like the most recent OpenVR API and also upping my page file. I know between this post and last it’s a lot, so I’m going to try to keep this brief and just answer any questions you have afterwards. Graphic settings never changed, I include an archive of all the relevant logs broken out by package – there are some redundancies here like the dxdiag and my settings so they can standalone with minimal effort. General observations: • Vanilla DCS was actually easier to crash and ran worse than my modded version, which makes sense since one of the two shader mods are is geared toward better vr performance (no flat shadows except cockpit) • Upping my page file also seemed to make things worse, the game chugged from the get go and never really stopped • I arrived at a standardized set of 7 SteamVR logs, basing this off of the web console • I tried to move my head noticeably when switching roles to help identify where the HMD blacks out, the Window will appear just to freeze, keep in mind that is the VR mirror being captured and not the DCS window itself • When the headset blacks out, the external lights do remain on, so it isn’t a full power down but the screen certainly is off Getting in front of things a developer might say • Yes, I forgot to grab the dcs.log on package 7, by the time I realized I had already ran DCS twice. I don’t think that it’s unique enough to invalidate the result as its not different than the scenario in package 4 • I know how much this looks like it is a hardware issue on my end, especially when we’ve ruled out mods and even some modules via the vanilla install, before blaming my hardware like a bad HMD/memory DIMM/GPU please remember how many other people are reporting this issue, it’s not like it’s mistakable either since the HMD actually blacks out • My temps were in line w/ normal • Nothing is overclocked • Index HMD is actually pretty new • My relevant software is up to date, this issue has existed across at least 3 different NVIDIA drivers and multiple SteamVR versions (both beta and ‘stable’) Notes The single attachment to this post contains all the logs and missions used for reference. I’m using your original mission, we will call it “mission 1,” mission 2 is the same as the original post, minus the A4, mission 3 while not used in the tests directly is an NTTR version of 2. Package 3: The precursor to this wasn’t captured, you will just have to trust me. I fired up my primary copy of DCS with the A4 in order to remove it from the test mission. After that I opened up the NTTR version of effectively the same mission to pull the A4 from it as well. The game chugged, as I said before it can happen in the mission editor ESPECIALLY when you select the list of units on the left. I exited the game normally, turned on the recording and went to fire up my vanilla instance and it crashed upon loading. So, in effect, the lead up as Alec described perfectly in post 4526701 persisted across DCS instances. When the crash happened on loading you can see the ram/vram isn’t even full, just some I/O. I included logs from both the primary and vanilla copies of DCS Package 4 – Mission 1: This one was a bit of a happy accident, I forgot to install the super carrier to my vanilla instance and still crashed it using our current steps. The SC slots are airstarts. This is good because the issue didn’t start for me until after the SC came out, this would rule out the SC just existing as a cause. Otherwise, this package represents evidence that we can crash it using the steps on a vanilla instance of DCS. Package 5 – Mission 2: This is a long one so I’ll just hit the highlights. The intent was to use what I saw in package 3 and see how it impacts the game, and that buildup that is experienced just by playing it somewhat naturally. I loaded up 2x missions into the editor and hit the unit list to intentionally introduce load that would end up persisting throughout gameplay. I then load up the mission and dance around with the AI for a while, the performance is pretty bad overall, it’s something I learned how to fix by alt tabbing for a few, I didn’t do it for the sake of this test and just let it ride. Things get interesting at the 22:56 mark where the game actually crashes SteamVR while paused and just running amok in effectively the background. Other than that not that interesting, included it because I recorded it. Package 6 – Mission 2: I updated to the latest openvr_api.dll file ( per Alec’s suggestion, as a note I reverted back to the included version for the next tests. This one was pretty typical of a natural occourence of this crash. I loaded up the mission, spawned some AI and then switched slots. This instance is probably the closest to when this happens out of the blue to me, as I wasn’t trying to prompt it and the performance was actually ok right up until it happened. Package 7 – Mission 1: For this test, I upped my pagefile to 32gb minimum and let it run up to 46gb+ to give a substantial buffer. I fell back to our published steps and actually crashed the game quicker than usual only making it to slot 3 of the mission (the harrier) Package 8 – Mission 2: This test is along the lines of replicating package 6 but with a bigger page file being the only difference. I went for normal gameplay, spawning AI to kill and didn’t get very far. Again not trying to prompt anything it actually crashed here without having to swap slots. DCS VR Crash Packages 3-8 and missions.zip
  17. edit: Cleaned up response to #1, corrected repsonse to #6 I'm going to try to respond inline to hopefully reduce clutter and (maybe there is a better way) fiddling with quote shortcodes. My response is in orange ----Begin response | Pikey text = Black, Stal2k = Orange 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. Ok, I don't want to confuse you, short of setting up a webcam looking into the lense - I'll describe it and you let me know if it suffices. This is true for both the Rift S and Valve Index. 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. 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. I do, and I will remove it and verify no mods as I've instanced a vanilla DCS instance for this testing. I'll supply it in a follow on post 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? Sorry, that was me being lazy since I forgot to screengrab them in either video or static form. MSAA 1 means the 1st option in DCS, so ya 2x as you noted 0=off 2=4x. 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. It is, as you noted DCS continues to run albeit in an odd state. It selectively responds to inputs (like keyboard) but it runs in the mirror at the equivalent of a ~4-5fps chug (I'm making an analogy here, not saying it's actually hitting 4fps). For example, when I actually exit it in the 2nd video, it doesn't respond to the ESCAPE command on the keyboard, but if I hit the little X in the window via mouseover on the windows taskbar, it will give the in-game optionto exit, I can click yes so it seems to take mouse but no keyboard input. A good way to approximate when the HMD is shutting off is when you see DCS say something about losing the TRACKIR input, or right when the crash happens the mirror will freeze up momentarily. 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. I was trying to get you a trackfile, normally if I just hit restart VR DCS will force close. Even though DCS is running, it's in a very strange state as it selectively takes inputs (mouse only) and runs like it's in a ~5fps state. I try to verbally exclaim when it's crashing as I have maybe a 1-1.5 second window of when I can see it coming and that the VR mic will still take input. 6) Which log are you tailing in the video? Doesnt seem to match the Steam ones you put in the zip It's sort of an amalgamation of the logs, I've adjust this to include which log is being reported on each line. I accidentally omitted the VRSERVER log from the archive, which is where you see the bulk of the relevant lines. In my defense there are 124 different logfiles in that directory :) , the compositor log would be the closest in the packet, my bad. Since I'm redoing this again I'll be sure to include it. I found a toggle to show the logs and can make sure I don't miss a pertinent one 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.) They should be unless I goofed up. DCS is technically shutting down normally for the reasons I've outlined in two other responses. If I need to expand on that further let me know. If it'd be easier I can 'kill' it like I normally would to get rid of information beyond the crash. As I said before I was trying different ways to get a trackfile out of it, if that isn't going to super helpful I'll just end the process quicker either via steamVR restart (forced close) or I can use the taskbar method which prompts a more normal shutdown 8] Do you have the Steam VR setting "Fade to grid on app hang" on or off? It's off, that should be evident from the VR on the left, when you see it come up "waiting" many games are really hampared with that setting enabled 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 I'll go through these and answer. I've created a second instance of DCS to use for this from now on to keep everything as vanilla as possible a) Code: 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. I use two shader mods, one is the removal of flat shadows from everything but the cockpit and the other is the better smoke shader. Just for reference, as I said I've moved this to a new DCS instance b) Code: 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. This is PROBABLY the result of me moving machines and not wanting to rebind 20 modules. I may have left prior instance of config luas that have the old USB addresses (strings) there. To your point I don't think this is causing a VR crash nor would I imagine the number of folks who are experience this issue have went through the same lengths I have to avoid rebinding :) Nonetheless the new instance should help here 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. Done, you are right there is a screen hook 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 My page file is not manually configured, it's automatically configured. In order to match yours I'd have to manually configure it. I have it on my NVME (C:) drive which is my OS drive, I run games off of other SSDs 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. Done 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. Totally understand, as I'm sure you understand I've 100% tried removing mods/repair/etc as one of the first steps before I became militant enough to partake in a 10 page thread on it :) I also don't like looking like an idiot, but am perfectly willing in this instance. That is why I went a step further and just made a 2nd dcs instance complete with it's own savedgames folder system. g) Code: 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 Nope it's not a recent install, I would speculate based on the entries that this has to do with me changing my settings to match yours. I typically have MSAA off, and put it to 2x to align with testing settings. Would it make sense to maybe run the mission first before record? I guess I'm that confident in my ability to crash VR that I just YOLO'd it there :) as you can see from the video I wouldn't say there was any 'unique' slowdown 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. I agree, that is why going back to my original post I think this issue is severely underreported and hard to get someone to take seriously (#triggerwarning Bignewy :) ). I've found it's best to look at it like a BSOD being caused by an application, sure it isn't the app itself crashing, but you get my point. The way I kind of rule out Steam as the culprit is the fact that it happens on the Rift as well. That completely sidesteps Steam, yes it happens to WMR HMDs as well but the relationship between SteamVR and WMR is pretty incestual so it isn't a free pass for Steam. On that note, and perhaps an important detail I have not mentioned simply because I'm assuming it's a non factor based on the amount of people experience this, because I DO have both Oculus and Steam HMDs, DCS standalone will open the Oculus software alongside SteamVR. This isn't avoidable and is quite annoying. I assume it's benign enough but as you've noted, dumber things have happened. To be clear 1) My rift and Index aren't plugged in a tthe same time and 2) When I've crashed it on the Rift I wasn't running the Rift through SteamVR. Other items you didn't ask, but inevitably come up in this type of troubleshooting are Tried different USB ports, 2.0 3.0 different controllers etc Aggressively disable Windows USB power maangement Have a sufficiently powered system (800w) Not using CPU or GPU overclocking, and as you can see from the FpsVR temperature isn't an issue ---End Response | Stal2k text = black I'll work towards getting another video together with the new instance. While not a showstopper, I would like your thoughts on the pagefile item. Should I effectively double it? If that is the issue I can certainly see that lining up with the amount of folks reporting this. If @VirusAM is still following this, that would be an interesting point of comparison since our systems align closely and he seems to sidestep the crash. Otherwise, the action items for me are Testing with Alec's suggestion of using the most recent OpenVR api.dll file, I'll be explicit about this as a one off unless it gives positive results (wouldn't that be nice) Either Adjust OBS to capture the full steamvr area to include the SteamVR fail window or work out some other way to denote the crash. Previously I've tried to do this with timestamps Remove the A4 from my original mission and share that out Make sure I include the vrserver log in the next packet Attempt to crash both with your previous steps and see if I can cause it more quickly using something repeatable. Without question I can crash it faster, but documenting the exact button presses would be difficult and likely not always result in a crash in the exact spot I would like feedback on the pagefile, because of the things we've covered off on I can certainly see that lining up with where I think we are ALL looking at this point. I'll spare my thoughts on how reasonable it is to expect people to know they need to manually set page files for a videogame vs fixing the problem to myself for now :)
  18. Sure I'll do it later today and let you know. Do you want the full video/logs I just did or would a simple yes / no to the crash suffice?
  19. @Pikey Here you go, all your steps were meticulously followed. I did get it to crash using those steps albeit it took longer then when hitting F2 multiple times, I was able to actually call the crash before it happened @6:37. One thing that does seem consistent amidst the chaos here is that going to a slot on the super carrier after you've effectively been somewhere else is consistently causing this between my original mission, this instance and when it happens to me during normal gameplay. Not saying it's the SC because it's happened in plenty of places where there wasn't a SC to be found, but it makes it easier to do "on purpose." Same deal as before with the trackfile, there just isn't a great way to grab it due to the way the game exits. Am I correct in thinking this is more of a nice to have since it's not going to mimic the camera changes? If it's going to be a gamechanger let me know of any workaround you can think of. I guess, if nothing else the steps you have listed do work in reproducing it for me, it just takes awhile longer. It'd be great if someone else having this consistently would take a stab at reproducing it with the steps Pikey outlined. edit: I'm an idiot and linked wrong video Steps for reference: 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. DCS VR HMD Crash Instance 2.zip
  20. I grabbed your mission as was able to prompt the crash. I realized I didn't do the steps EXACTLY as you listed so I will do this again, in the mean time I did want to supply the video with the realtime SteamVR log. I couldn't get a trackfile because of the way the game exits, but everything else is providable. FWIW it was actually harder to prompt the issue on your mission than the original which was notably lighter. I know you hate speculation :) but it felt like I REALLY had to try make it crash on this mission whereas in the old one you could attribute the actions neccessary to normal use. Without knowing much about how DCS handles this sort of thing, the one item that sticks out to me is the number of slots - on big servers and the original mission I used there were a lot of slots, could be nothing but it was interesting. I really am sorry I didn't read the full post to understand the exact steps and settings you want used. Mine are currently more conservative (included in the zip package) but I hope the video with the telemetry is still worth it. Two notes, 1) If it's not clear from the FPSVR capture my SteamVR SS was at 150% and the HMD blacks out when you see DCS crash happened on the F2 press at 3:42 and the logs settle at 3:58. You can also see DCS disappear from the SteamVR window on the bottom right as a good indication of when it blacks out. Again, sorry I didn't follow you directions exactly - I will do it again, but since I'd already recorded it I didn't want to just scrap it incase there is insight you or anyone else can gain from the view that I'm not seeing. DCS VR HMD Crash Instance 1 Logs.zip
  21. 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?
  22. 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.
  23. 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.
  24. 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.
  • Create New...