durp

not that I can contribute much at all, but it worked end of last year and beginning of this year, some update broke it, regardless of 'external' scripts. either 2.9.6 or 2.9.7 broke the replay system (again) and with the cinematic camera feature and such, I was hoping this would be tackled at some point, but now it just 'external' scripts.

park somewhere and go to the F10 map and back to the cockpit (F1) that issue is present since day 1 they added MT the first time to DCS back then. there's probably more threads about that.

This issue has been around for quiet a while, fun fact, since the introduction of MultiThreading. It never got fixed so far. There were some posts here and there about the broken auto brightness adjustment (also not addressed yet, other than turning on global illumination) On daytime the effect is an overbrightness when switching from the F10 map to the cockpit, at night, the total opposite. at night, this is how it is supposed to look: this is what it looks like when switching from F10 to cockpit without moving a lot: workarounds are to hammer F2 to get to another plane and then switch back... the same issue in reverse: this is how it is supposed to look like: this is what it looks like after switching from F10 to cockpit Running, as recommended, in MT mode, Gamma is set to 1.6 to balance the nuclear look after swapping from F10 back to cockpit. And if the adaptive brightness is not already bad, this is really annoying, particularly when at night everything gets so dark, you can't even see the NVG overlay anymore. Other Link(s): and maybe more...

well it's like a hit and miss not just finding the right thread about it, sometimes replays work sometimes they don't. and as someone already mentioned, the chance is higher if the replay is short and one does not respawn. Can those threads be merged please? Seems to occur quiet a few times. And as for the attempt to have not tacview running, nojoy, same behavior. The only constant is ST (working) vs MT(sometimes working, most of the time not working)

Tested it yesterday, works only once per helo, so it seems. Could be also related to the scripts they are using on the server (4YA) Cargo is selectable and can be hooked, but once it's dropped, one can only cancel the cargo request, but nothing happens, menu is stuck in that option, so you can't re-sling load it or pick up new ones. Did not test it offline since I never fly offline.

seeing the same on the 4YA server, line goes somewhere across the map, does not hook. Pretty sure it worked before DCS 2.9.4.53549.

Well, at first that seemed promising, as a few trackfiles do work and those were the ones without respawn... but after digging through some tacviews to find tracks without respawns or any incidents, found also many of them not working, same error. Barely had any issues with replays in the past (other than desync) Replays from another one from the same sessions do work, difference here mostly is Intel(him) and AMD(me), even got the same VR headset. (EDIT: both are on AMD CPUs) Will try without loaded tacview mod, see if that makes any difference.. but all private-server replays work, even with tacview... not so much expectations in this... Theres also: those are the same problem.

Could be. I will ask someone who uses the Standalone but uses SteamVR (Index, same as I use) what their parent process is, but I do expect it not to be steam.exe, since it's standalone. (He doesn't observe this behavior.. but neither he bothers about frametimes) Unless there is a way to start DCS without the need of Steam (aka without steam.exe being the parent) I would have to switch to the standalone for a testrun. Can't do that now as VFA is in 2 weeks. My guts feeling tells me that the increased frametimes won't be observed then... but.. might also be SOL and the problem would persist.. just without any workarounds anymore... and I would have to wait 1 month before I can swap back to Steam.... (picked up that switching between steam<>standalone requires 1 month in between) Can offer a process dump, if ED is interested, via a ticket, and/or if there are other tools/stats I can try, just mention them.. maybe there is something that can give some insight. I (personally) suspect that dcs.exe is launched either in some sort compatibility mode within steam (particular because what is displayed during DCS launch) or that dcs.exe inherits some priority/affinity settings from the parent application (steam.exe)

The difference in the logfiles between the two 'states' in my case are already posted (literally went with a diff tool over them), the only different values are: pause10, standard deviation which could mean that the times are all over the place.. and they are... judging by the graphs. Thread wise, the only other difference I have found so far is that on the first launch via Steam, the parent process is steam.exe and after an enforced relaunch of DCS the parent is the previous instance of DCS (dcs.exe) I don't know what else to check, I am open for ideas, could even do process dumps for the good&bad runs and alike (via direct contact or ticket) So far it is consistent for me that after launching DCS the frametimes are much higher (mainmenu, in-game not playable) and a simple settings change followed by an enforced DCS restart sorts it out. Slightly worried what else will happen, MT was running really good before (with the given limitations). At least I have a workaround for now. Another symptom I have observed on the 2.9.1.48111 release is that SteamVR started to show the desktop on the VR headset while launching DCS and that the DCS authentication dialog was displayed in the VR headset... it did that never before... which made me worry this is running in some sort compatibility mode... and this does NOT happen when launching the ST version. PS: I tried the symlink trick to have bin and bin-mt refer to the same directory and launch DCS via commandline, no joy, the parent is still steam.exe

SteamVR performance graphs attached. There does not seem to be a different command-line argument between a regular start and a DCS-enforced-restart, checked with processexplorer Just started DCS today, no settings changed since yesterday ('acceptable performance yesterday'), frametimes as bad as mentioned before, graph is from mainmenu, as expected in game not playable (not shown, refer to previous post) went then into the options, toggled fullscreen to force a DCS-restart (the value of the fullscreen setting does not matter, it's all about the fact that DCS does require a self-triggered restart) and the frametimes were acceptable again, in mainmenu (shown), but also in game (not shown) (aka acceptable in game performance) process explorer performance graphs (not much information shown, except the CPU usage) 'bad' state with mainmenu frametimes of 9.9ms 'good state', mainmenu frametimes ~1.6ms some differences from the logfile (badrun, vs goodrun): (pause10, standard deviation) // BAD RUN 2023-11-24 10:32:20.337 INFO EDCORE (Main): pause10: 0.016800 us (std dev: 0.014967) 2023-11-24 10:32:20.337 INFO EDCORE (Main): pause10: 583 cycles (std dev: 410.2) //GOOD RUN 2023-11-24 10:07:31.261 INFO EDCORE (Main): pause10: 0.016777 us (std dev: 0.005829) 2023-11-24 10:07:31.261 INFO EDCORE (Main): pause10: 583 cycles (std dev: 429.7) rest does not show any real difference (other than TIME and THREAD ID changes) (and I hope those are not really sleep calls in the loops for thread synchronization....) ------------------------------------------------------------------------------------------------------------------------------ I am not much into benchmarking/performance graphs, maybe there are more/better tools that might give some insight. Happy to try those and post the results. Noteworthy from the SteamVR performance graph might be 'compositor update end' and most noticeable the 'application interval' Settings are the plain vanilla "VR" settings in DCS. During testing the last few days I did also rename the config folder. At least for now... all I have to do to run DCS in acceptable performance is opening it, and if the frametimes are ~10ms in the mainmenu (which is almost always the case, except once, where I had 2.5ms? didn't dig further as I was doing this to compare the log files) goto the options, toggle a setting that requires DCS to restart (i.e. fullscreen, and again: the value does not matter, just that it changes to enforce a DCS restart) and once DCS did restart itself, the frametimes are at 1.6ms in the menu and in-game performance is acceptable again.

Okay, I do have some update on this one too..... It might have started in the initial 2.9 release, but I am quiet sure it started with DCS 2.9.1.48111. The issue is the similar/same? as @speed-of-heat does have...(it reads like the opposite) the CPU frametime is about 10times higher than usually in the main menu. (in MT) Instead of 1.6ms CPU frametime (what I usually got), the frametime is between 9.8-10.6ms. but even with this frametime it cannot maintain 45fps (VR), but it should... This performance drop is also carried over into the game itself, not just the menu, and it's not playable... After trying many many things, suddenly I noticed it went back to 1.6ms frametime on the CPU, and on the next DCS restart it went up again. Literally all that is needed to 'alter' this behavior (this is NOT a fix) is to change a setting in DCS that does require DCS to restart. (toggle full screen display on for instance, even when on VR, it's all about the enforced restart) ..and DCS is back to 1.6ms frametime in the menu for me and the in-game performance is great* again. It tanks the performance again when I close DCS and open it again, have to do a settings change, which forces DCS to restart, and then it's fine again (for that session) * with the given engine limitations... So something does happen when DCS is restarting itself, I did not check if there are different command line arguments being used. I have it on Steam, and without renaming the 'bin' folder and create a symlink (or just copy over the stuff) there seems to be no way to start the steam version in mutlithreading via commandline. Left: (mainmenu) DCS unable to reach 45FPS (VR setup at 90Hz, mathematically it should be able with those frametimes) Middle: (mainmenu) after changing *any* setting in DCS that does trigger a DCS restart, Right: (in game) when the frametimes were inflated by x10 already in the main menu (left screen), it is not playable that way.

When launching DCS in MT mode via SteamVR I recently started to get the virtual desktop shown in the HMD and the authentication screen of steam is being rendered in it in a massive stretched way. (The screenshot below is from the VR view and does not look like the dialog box (the blueish/graying box is rendered across the whole HMD, maybe I can get a capture from OBS for that) This looks to me that Steam VR does not detect the game as native VR game anymore ?!?! It launches in VR but the loading happens in 2D in the virtual desktop... which I suspect there is some compatibility mode. (This does not happen in ST) Currently investigating some massive unstable CPU frametimes since the last update.. as if the thread scheduler got changed. Among with the way SteamVR now starts DCS I have the feeling that this is running on some compatibility mode... Had similar frametime issues when I tried back then to force the OpenXR toolkit when in MT, ditched that within seconds. Now the frametimes are neither stable nor playable, the only thing that changed was the latest update. left side is DCS 2.9.1.48111 right side some screenshot before the 2.9 update. Rather than going into troubleshooting, this post is really only about the question if the SteamVR handling and/or the thread scheduler got changed/updated? (if there were any changes, nothing mentioned in the changelog, but that doesn't mean a thing I learned over the years...)

I can't add any meaningful insights into this, other than since the last update (DCS 2.9.1.48111) there seems to have been a change in the scheduler? Loading up DCS (VR) gives me a frametime at 23-26ms in the menu often enough, it was supposed to be around 1.6-2ms before. Noticed also that when tabbing in/out sometimes the frametimes improve by over 15ms, sometimes after several launch attempts it also seem to run normal again (at least in the menu) This seems to be more a hit or miss situation now, freeflight supposed to be on the given settings at around 7ms CPU frametime, now often stuck at 25ms. I have not found a reliable way to keep the performance somewhat stable . (AMD CPU) Did not spot anything in this regards in the changelog...