durp

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.

Before the update today hits the shelves.. a small update. There was a Steam (VR?) update 3 days ago, and it seems the 10x performance drop on initial launch is no longer the case. Menu launches into a 1.6ish ms frametime now without the need to force a DCS restart and in-game performance is okayish (neglecting the other issues with 2.9) It was also the only update (steamvr) that did change (15th Dec), nothing else. (can't exclude quiet updates as with the F15E model 'fix' on accidental release) So far the last few DCS starts went alright, can't say much about it, it is literally just 3 launches of DCS so far. Just wanted to toss that in before the update comes out.

I am on AMD, the IO cores are the same between the runs for me, the standard deviation on pause10 is higher. good run: INFO EDCORE (Main): common cores: {40, 41, 42, 43, 44, 45, 46, 47, 16, 17, 18, 19, 20, 21, 22, 23, 48, 49, 50, 51, 52, 53, 54, 55} INFO EDCORE (Main): render cores: {32, 33, 34, 35, 36, 37, 38, 39, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} INFO EDCORE (Main): IO cores: {24, 25, 26, 27, 28, 29, 30, 31, 56, 57, 58, 59, 60, 61, 62, 63} INFO EDCORE (Main): pause10: 0.016777 us (std dev: 0.005829) INFO EDCORE (Main): pause10: 583 cycles (std dev: 429.7) bad run: INFO EDCORE (Main): common cores: {40, 41, 42, 43, 44, 45, 46, 47, 16, 17, 18, 19, 20, 21, 22, 23, 48, 49, 50, 51, 52, 53, 54, 55} INFO EDCORE (Main): render cores: {32, 33, 34, 35, 36, 37, 38, 39, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} INFO EDCORE (Main): IO cores: {24, 25, 26, 27, 28, 29, 30, 31, 56, 57, 58, 59, 60, 61, 62, 63} INFO EDCORE (Main): pause10: 0.016800 us (std dev: 0.014967) INFO EDCORE (Main): pause10: 583 cycles (std dev: 410.2) -------------------------------------------------------------------------- Did compare if there are different DLLs loaded between the sessions (goodrun vs badrun) badrun loads following DLL extra: 0x00000000e0370000 0x98000 C:\Windows\SYSTEM32\webio.dll goodrun does not load webio.dll but loads following ones (not present in the badrun): 0x00000000ec330000 0x11000 C:\Windows\system32\wbem\wbemprox.dll 0x00000000ec2a0000 0x90000 C:\Windows\SYSTEM32\wbemcomn.dll 0x00000000e7c90000 0x14000 C:\Windows\system32\wbem\wbemsvc.dll 0x00000000e7ce0000 0x10b000 C:\Windows\system32\wbem\fastprox.dll (don't mind the different memory addresses) The filelocations seem to be consistent, was hoping to find a DLL file being loaded from... wherever, like an old openxr runtime. badrun means, starting DCS regularly, from steam (or via shortcut, same thing), CPU frametimes in the mainmenu are ~9.8-10.6ms, in-game not playable goodrun means, after starting DCS and change ANY setting that requires a forced DCS restart, after that frametimes on the mainmenu are 1.6-1.8ms and in-game is acceptable performance ..and as for now... this is always the case that the regular DCS launch results in bad performance, and after changing ANY setting that requires a DCS restart, the performance goes back to acceptable levels. Closing DCS and reopening it (via Steam) results in a unplayable badrun again.

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.

I can only add that the last update increased the frametimes for me in the menu from 1.6ms to 10.5ms (CPU) and DCS can't maintain 45fps in VR that way (in the menu!), despite both frametimes being in the green. The menu is not 'stuttering' or lagging, but that drop in performance in MT is massive and flying in MT is no longer an option.... In comparison the ST version has a CPU frametime of 0.8ms in the menu and and the HMD is locked at 90fps (HMD max)

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...

thank you, done, just sent them, including another finding I just made on another system

Does anyone else have the issue with the EDM plugin that one can no longer use the file > export > export functionality in 3ds max? 3dsmax (2023 & 2024, I can't go really older) crashes when doing that, regardless if the scene is empty and manually moving the files out of the plugin dir when not doing DCS stuff is slightly cumbersome... Just buy going to file > export > export, it instantly crashes 3dsmax, the 'edm export' from the toolbar however seems to work (I can't tell, other than a few test EDMs I haven't done with it yet) this is not really on how to use those EDM tools (started learning DCS related stuff) but more of an "how to keep the host application functional with the ED plugins installed" issue. it simply breaks 3dsmax export feature, regardless of using it for edm files or as in most cases here for other things. (did install various versions, just not sure how far to go back in time with those, particularly as 2024 support was added in April) I would be happy for any hints on which plugin-build does not crash max when going to export, for now I have to manually remove the plugin files in max Could go up to 5 versions back, which should be 2020, but this would be a really specific DCS case and when autodesk releases their 2025 series, the oldest to get would be 2021