Pikey

Same, log out, log in, went. not sure what is going on there.

After testing it does seem so. So basically without the server install, you will get a 10min delay no matter what.

I wouldn't bother touching the main installation for things like that. The way DCS works is that the profile (Saved Games\DCS\) overwrites the settings in the install and the miz file overwrites the config, thus you have three layers of inherited settings. That's how your mission can overwrite your user settings which overwrite your games default. :) TLDR; in the \username\Saved Games\DCSfolderYouActuallyUseNotYourLegacyReinstallFromWhenever\Config\autoexec.cfg

Similar issue. Can I confirm that ALL CLIENTS connecting to a DS server that does not have Tacview installed have a mandatory enforced 10 minute client side delay added, regardless of what the client sets? On a server with no Tacview installed but which exports and also has the Tacview variables defined, clients have the message, "Applying playback delay of 10 minutes to prevent cheating". Since this is our squadrons persistent server we don't have a cheating issue to solve but we do dislike waiting ten minutes to disconnect to evaluate dogfighting. It appears (and it's really tough to understand this after reading and using this software for so many years) that, you must have Tacview installed on the server for clients to bypass the 10 minutes delay, which can be a nightmare to setup for servers with multiple installations and profiles - we really don't want to add any burden to the servers for performance, hence this is why we put the debt onto the clients to take their own Tacview. Hope that makes sense, is this unavoidable?

Checked on HP Reverb. Shared parser it was on all cockpit floodlights and lamps, I removed the line and they were all shown in both eyes normally. 100% this is shared_parser

Are these with or without shared parser in the config?

This has been requested for some time now, the problem is always you guys were never supporting the report of these issues at the time. There are so many reports of lighting related issues, especially the dots that if we cannot create super threads of customer wishes together, we lose traction. This has been an issue since March and release of 2.5.6 with the dots. The other lighting stuff I will bump again though. It's all tied into object distance and display. I beleive that once the object goes out of display range, its associated light is lost and thus, no ambient light = weird compensation required for ambience.

I tried a few versions but theres a minor bug with the process detection still in the current release. Depending on how DCS was closed the App doesnt recognise that the process stopped and then treats DCS as running but here's the issue: 1. When it thinks DCS is running it locks off the app from running DCS.exe again - rendering the app dead as a launcher 2. Force terminating the ghost dcs process via the app results in a JIT script crash 3. Restarting the app has no effect, this is cached for some reason and doesn't clear off. The problem is really no.3 because it prevents working around the problem. I'm not sure how or why the process is detected as running when it is not, the process and pid are tracked perfectly in WIndows, a simple query will never give a ghost result, so it just needs some tweaking here. Otherwise.. couldnt live without it. Thanks.

I found http://www.spitfireperformance.com/spitfire-IX.html which probably gives the answers but doesn't help me understand the physics and the why.

It's not often I ever needed to go high, but I am struggling to find out where the Spirtfires 'happy altitude' is. I know that altitudes depend on pressure, high level winds and such but generally higher is better for jets. Props are a tad more complex, so where is the Spitfire mk9's cruising best performing altitude? I read that the LF.IX was 404 m.p.h. at 21,000 ft. and this was the altitude at which it's top speed was at that day. Does this mean 21,000ft is also a good goal for cruise? Just to be clear, the purpose would be distance and speed rather than fuel performance but if someone could provide one answer for distance and loiter/fuel it would help me also to understand.

For those of you Mudhen lovers that only want it and don't care about other things..."Todays Harrier is tomorrows Mudhen". If RB do not give the complexity of the AV-8B serious time and effort it spells disaster for something as complex as an F-15E. That they care about it, is by far the most important message in this post, whether it addresses all the points raised by the EA purchasers or not, it does at least give the TPOD a good going over which was a primary concern. Thanks for the update.

We've seen this for the last 9 months by reproducing with MOOSE GCICAP type scripts which make heavy usage of "RADIO" altitude. It's often easy to get this to happen via scripting. I've no idea why RADIO is even useful at high altitude, it should probably be deprecated as it causes problems that will cause AI to stop responding to instruction, get pegged at 30 degrees AoA and climb slightly until runnning out of fuel. Really the AI should be refactored to use "RADIO" (AGL) when flying very low and "BARO" when their line of sight is unobscured. AI still avoid terrain, its really only useful for getting helicopters to go down into valleys and fly noe, that's it.

Create a new thread sir. Your issue is not related to this one which has long been fixed.

With two F-4, with AIM7 and AIM9M head to head 20nm both with CAP task primary and RETURN FIRE ONLY as second task in adv wp actions, neither of them shoot (as expected) As soon as I removed the return fire from one of them, it shot and the other responded. Seems to work as expected?

42VFG is now expanding to the WW2 arena. We are regularly having fun with the Spitfire on the Channel map, with the assets pack. WW2 is making leaps and bounds recently, if you haven't checked it out in a while, now is the time! Our WW2 stuff is less process oriented and less hardcore. However, when revisiting WW2 we steal something from modern processes, like AREO calls and good solid brevity which translates back and forth very well. But it doesnt mean we don't sometimes lean out of the cockpit in VR, into the slipstream and try to shout over the wind... ok?! :) (We fly throughout the week, casually but aim to do an organised session on Saturday nights)

http://www.atlantikwall.co.uk/atlantikwall/fpc_gris_nez_luftwaffe_audembert.php Audembert was the closest airfield and home of JG2 for a bit. I think the Channel DLC map is missing this and it's also quite relevant to the map.

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