Worrazen

Better visualization indicators of stacked waypoints where waypoints are almost or exactly on top of each other and ability to hit some kind of a hotkey that separates them, the ones that fit into a predetermined "close enoguh"criteria could be visually separated with the indications appropriate indicating this is in effect, and for safety to not get confused it should only be HOLD down action, IMO. ---------------------- ---------------------- Ability to filter various ME item indicators, such as waypoints, units, on a height basis where applicable, so a filter of 1000 meters would only show units and their waypoints that are at or below 1000 meters, in cases where one unit group's path crosses this limit: the preceeding and succeeding waypoints would show a short arrow indicating direction to their neighbour waypoint that is hidden, for the preceeding waypoint it would show an outward arrow that extends a few centimenters on the monitor screen, not the full length, pointing to where the hidden (filtered) waypoint is, and vice versa for the succeeding waypoint that passed the filter, Perhaps a number could be added in () parenthesis at the preceeding and succeeding waypoints that pass the filter, how many hidden waypoints are there. In a way that this number doesn't confuse with the ID number of the waypoint so I'm not so sure about this. ---------------------- ---------------------- Ability to clone/duplicate units while keeping their waypoints location (clamp to source) except the waypoint of the actual unit spawn location. This could be part of an advanced paste/duplicate options menu, where you could select this option and additionally you would have 3 textboxes where you could enter numerical offset for the waypoints for X Y and Z, with the unit's spawn location waypoint ofcourse being exempt from this adjustment. So you would have the ability to adjust this very slightly than it is possible with mouse by moving things around. The X and Y may be redundant so perhaps an option for fine movement could be added to the normal duplicate method instead. However the heigh adjustment for all waypoints that are being copied is very much welcome, something that I think can't be done now (multiselect?) Sometimes I've wanted this for particular cases when I want units to go in a particular path in a very narrow river channel or valley, the unit collision is not an issue when the speed and initial start location is adjusted but yes it is more prone to such occurences, a skilled map maker will make sure this is avoided nontheless.

Reason for stuttering besides VRAM is also because the engine seems to require some data from disk that it needs to continue execution, I am in the middle of another session of investigating into this, what I have been suspecting for years and that's why the move to SSDs and NVMe for DCS has made a big difference. If this is 100% techncially correct I don't know, whether that's a bug or just how it is, geometry most likely isn't streamed and models have to be fully loaded, that is normal for most such software so what I think is happening is because the assets aren't loaded in the beginning and have to be later on right when they're needed. Another reason for stutters is CPU, because terrain asset (textures) loader threads require quite a bit of CPU and can saturate a lot of cores and this will determine the speed at which your textures will pop-in, so it's not just disk speed and responsiveness. However terrain texture streaming never causes the engine to stop executing, something else is causing that, something that is more random and obscure and I've yet to dig into it. Why I haven't done this yet is because it took some time to peel away all the other sources of stuttering and then isolate and identify the various kinds. I will post a thread to the DCS 2.7 Game Performance Bugs section (unless 2.7 fixes this) in a few weeks or so. The stuttering I'm talking about may not even be noticed by many because it's subtle, a few frames here or there, but still.

Exactly, especially all the side stuff you could do with it, base maintenance and repair, dropping supplies down so combat engineers can finish constructing a new military makeshift bridge, need construction equipment to repair key road or bridge there, ... the only limit is a comparable real-life case, they do strap parachutes on smaller armored vehicles, but I haven't seen an excavator yet or other stuff, so I guess all of this within reason ofcourse, almost got too enthusiastic there haha! If you can't rescue a pilot you can drop down a supply crate, where he can hunker down for the night or more, or even a cargo truck with a pair of paratroopers that can expedite the pilots relocation to a more suitable area for evac, imagine the cross-over gameplay with Combined Arms then, of the human driver in that truck driving through woods and hills, being guided by fractured information from a AWACS and CSAR helicopter or A-10C, and you have the comms being affected by jammer here and there it is, it's DCS baby! So all of this transport and big-jet stuff won't go down to, this should all count, you could put it, as a pre-requisite technology for a really good and deep CSAR experience down the line. And what I mean with CSAR is not that it's CSAR for the fun of being a medic/emergency/services in some kind of an EMERCOM Simulation, while that alone may be fun for some of us including me, but in DCS, why do I keep harping on CSAR ... because rescued pilots and salvaged airplanes (a bit of a stretch, we'll see) /debris/cargos/etc would actually COUNT for the Dynamic Campaign economy and you would have a pretty good reason to use CSAR as in real life. CSAR is of the things that I think gives Dynamic Campaign that source of depth and other objectives, more layers of sub-missions and secondary/tertiary objectives, which is exactly what Dynamic Campaign scenarios would benefit from, it makes the Dynamic Campaing it self stronger and richer.

Transporters and tankers hopefully before Dynamic Campaign. If you ask me on a subjective convenience sort of a viewpoint, I'd even delay the release of the Dynamic Campaign or at least it going into release status before the infrastructure-transport-supply-cargo units are freshened up, even tho the visuals I guess don't really have any direct connection to the Dynamic Campaign, but my idea is a bigger one, to have these transporter and tanker at other units designed/updated with the Dynamic Campaign supply-cargo-transport-infrastructure interoperability in mind so that they feature the animations needed for the supply-transport chain to flow like butter, and some extra fucntionality where applicable and/or possible while still being AI units, as a compromise for likely no a full fidelity heavy aircraft so soon. Within reason tho, I think this is it, new ATC probably not a chance, according to what I heard in a recent interview. It's sort of interesthing how each of these things is a bang on their own, but when you count Dynamic Campaign into that it kinda feels like the combination increases the power by a magnitude rather than just twice. It's like sugar spice and everything nice, but there comes the chemical X.

Not like it's anything new for the experienced folks but this is the fist time I'm seeing anything like that, loading full blown helicopter into an Ilyushin transporter, I mean, it's not surprising to me, I just happen to never though about it even tho I watch this sort of stuff and I know you can load a lot of stuff on cargo planes. This is the compromise of lack of an AC/C-130 full fidelity module, a gread transporter AI's with such ability in DCS and perhaps some cool animations with external model along with it. I think this is a fair wish considering all the circumstances, DCS has yet to have a 2 engined airplane for the first time ever, yes, I understand.

Well thanks! However many different causes share similar or same symptoms in many cases so I wouldn't just conclude this is the thing behind your issue, it's a bit of a stretch because it's just not noticable at all unless you go looking for it purposelly like I did. You would have to first know about it's existance, then purposelly benchmark a big mission with the offending thread disabled and enabled, only then you could compare the results, and the results wouldn't show difference in most usual SP mission cases, excep the very active scenes, unless you test for the maximum strain, like a crowded Multiplayer in a demanding map. The biggest thing that it affects is simply electricity, secondly it's the other Terrain Asset Loaders that are loading up the terrain textures, which means there's a range of extra delay that it takes for these textures (LODs) to load (Show), which may be very hard to detect if one is not paying attention and specifically focusing on that. It may affect everyone, in that this is the normal and there's no comparison to anything else, so it goes undetected. Thankfully it just doesn't have much of an effect on average FPS, because the main and GPU threads would work the same whether or not this one is taking some extra from the otherwise idle CPU cores or not. However, it could be behaving different on different machines, for example NVidia GPU users could have a different experience, if these variants are true then yes a substantially higher CPU usage on this would indeed make a difference, but you would still only be able to notice it if you actually compare your FPS/experience with someone who has a very similar or same PC, only in that case would it become suspicious from the outside.

I will try, but wouldn't that also disable when I do actually get mentioned like @Mentions and when someone replies to "My Content" is how I'm understanding it works, because I do actually want notifications on replies. We'll see.

Right until this point I totally mistaken about who this intervew was about ... oops, so maybe the questions I had weren't that fitting. I thought this was with the Founder of ED. One of those moments when eyes read something and the mind sees another.

Hello The notification settings do not have any way to disable and control notifications about reactions, when someone likes or reacts to a post. I would not like to receive notifications on such events. Thanks

Thanks, I've been doing my homework recently giving the lesser known aircraft (relatively speaking) some more attention they deserve. I'm very much interested in the technical and practical differences in the way cockpit systems are designed in comparison to the commonalities in blue and red for across different aircraft. Sometimes I wish reality was even more diverse, so I kinda dislike many other countries just purchasing aircraft/arms from only a few global suppliers/powers, so I was quite enthusiastic about JF-17 while made with a lot of off-the-shelf parts it's still rather uniqe way it was put together, I like that really much.

Dang I wrote the whole post before the forum restore feature overwrote it when I hit reply ... I was saying, if it's an attachement probably the image isn't re-encoded, you should expect EXIF to be still present. Hosting sites usually re-encode images, and I think with IMGUR I did test and it does not contain EXIF, though it would be possible to re-insert it (carry it over) or if they have a "original quality" feature, but didn't test that. Now things could have changes, this was years ago as far as IMGUR goes.

@ribeye If you have any other data you think you may need on that disk, then out of precaution please STOP USING IT IMMEDIATELLY especially WRITING anything. Hopefully ... well I see it's C:\, unfortunately it is your system disk, you would need to stop powering on the PC with that disk, because just running it will produce writes, although not so much any kind of use is never a good thing when signs of a failing disk. Because it is a system disk it complicates things, you would need a spare disk preferrably, but it is possible to do without it. However you still need another PC to download and flash a linux ISO onto a spare empty USB storage stick. You can ofcourse risk to do this on the current system, but this is just asking for more problems. What you would do is to boot into a live linux distro of your choice, and install smartctl / smartmontools and GSmartControl (GUI for smartctl) You would run a long and/or offline test to do a good check on your disk, to make sure there's no issue. However you would need to look at the documentation quite a bit first or ask the communities about how to use the program. Keep in mind SMART deeper checks aren't normally running when drive is normally used AFAIK, unless it's some vendor feature of the firmware to do it automatically at long idle sessions (according to logs I have not noticed this at least with my WD drives), and even after detection of a problem SMART data takes a reboot or two to populate which is what the OS can then use to report, so issues with disk happen before there is any warning or any notification about it, depends on the situation. On the other hand you could, if you just don't want to deal with linux, install a windows version of smartmontools on another Windows PC you might have or would need to borrow, but the program is still the same command line thingy like it is on linux. I'm slightly out of the loop on whether smart tests will let you do manual tests while the drive is in use, and not just in basic use but literally running an active system, but it's just not a good idea AFAIK, the device might have to be unmounted anyway for the test to be able to start. Finally you might be able to have such tools by your disk manufacturer but it's more of a not standard thing, WD has/had Data Lifeguard tools which I belive are very old now from the Windows Vista days and might not even work on latest Win10 but you could try, for smart tests you don't even need to have a WD drive as this is all standard but with WD Lifeguard tools I don't know because I never had anything else other than WD (lol, I do have some old HGST now but never tried that), althought some of this is plagued by bloatware, requires internet connection to function, Samsung Magician will literally check with server the serial number of your disks every time it launches and tools/features are locked out if it can't confirm OK from server (at least it was 2-3 years ago when I last checked). https://www.smartmontools.org/wiki/Download

4 Engines is the whole reason I'd want it, I'd love to experience that kind of redundancy, providing support with 2 broken engines perhaps, that would be some fun tense gameplay .... all depending on that key fuel or ammo shipment and the whole battle is around that limping C-130. Well, we can emultate that kind of gameplay scenario with AI's as well on the other hand, but then it's all about how deep the attention can be for AI C-130. I would really like some kind of a compromise where several AIs that are really important for adding gameplay in general and Dynamic Campaing, but are really hard to be justified for full fidelity, should be put into a new category of AI units that get extra attention and would have more depth to it than usual, ofcourse could be done by 3rd-party too, however then it's a bit more difficult defining a standard and if that's worthwhile at all, I mean, this "new" segment idea would mostly be for documentation/discoverability, it's not like newest units that we're getting now are sticking to some old or whatever standard of how it should look/feel/depth, at least publicly, DCS development is quite dynamic. So it wouldn't necessairly have to be segmented, but that would really help out having a good overview of DCS, and to track these extra changes such AI units would get, and in future there will be lots of more side units and in general it's growing steadily, DCS might use a good chart about then.

So I spent 2 hours writing about it yesterday, then I accidentially closed the tab without backing the text up, and the forum which does have a save function did not restore this reply unfortunately, perhaps I kept the tab open too long (several days, session expire?) or because I "reopened closed tab", which does work in general but it didn't in this case. So I guess I'm going to see if I can restore it from process dump, otherwise I hope I can rewrite it in time, if I'm not too late already. I will edit this post. EDIT 1: Okay I think I have all or most of it, there's 2-4 main short questions, it's just my eagerness to speculate and thinker that is long which isn't that important I guess anyway in this case. I'll spend some time cleaning this firefox memory dump text out hopefully, but here it is just in case. --------------------------------------------------- EDIT2: I have also reworded and shortened things a bit on the second run-through, it should in principle be the same. I may have more than just one, because some of it is just so connected and branches out, these are sort of drafts I kept mulling for months which I wanted to post to Wishlist and I will after the fact so I'll just keep going as I have to write this stuff out anyway for later use, keep refreshing this post. So just pick what you can and what makes sense for the episode, and ofcourse it can be modified to make it shorter and more to the point, I'm notorious for taking a lot of words to say something. ------------------------------------------------ FIRST QUESTION: Would the so called Dynamic Campaign have a different (proper) name/description after it is released for public testing for the first time to better distinguish it from other products and various perceptions that the community has constructed over the years as part of the anticipation of it's release? I have made a thread throwing various terms out here: ------------------------------------------------ SECOND QUESTION: How approximately deep is or would the supply and cargo cross-functionality with civilian infrastructure go at launch of the Dynamic Campaign or in the near term, or is this planned for later? Lengthier explanation of the idea and thinking behind the question: ------------------------------------------------ THIRD QUESTION: Can any rough comments be shared regarding general radio functionality and radio signal propagation simulation enhancements for communications in DCS, if there are at least plans, which is I think is an important underbelly of a lot of very interesting topics such as the New ATC, DCS Voice In-game Radio Integration, Unit Group Comm/Data Link Simulation (Launcher-Radar, HQ-CommandPost, etc), my cup of tea the Combat Search and Rescue someday, which would rely on signal sniffing where such improvements would be welcome to have. Lengthier explanation of my idea and the thinking behind the question:

To my knowledge SLI/Crossfire require a lot good of support from games/drivers and all around as well as perhaps manual fine tuning to work out, and also will by design be susceptible to micro-sttuttering AFAIK so fundamentally not optimal for gaming. Anyone with spare GPUs or just unlimited budget could still play with it but the industry realized for most gaming this isn't the way to go and so CSX/SLI is practically dead in this market segment. In the latest generation, Nvidia removed SLI support outside enterprise compute GPUs anyway AFAIK, even the 3090 for the enthusiast segment doesn't have it. https://www.pcworld.com/article/3573384/rip-nvidia-slams-the-final-nail-in-slis-coffin-no-new-profiles-after-2020.html

Oh, I didn't mean that post to come out sounding like that. I was speaking in general in computer software, historically a major version bump indicates a lot of changes all-around, it doesn't have to be so in this case as hardcore as it used to be. I'm a bit grumpy when it comes to fast versioning and I rant about it everytime I get the chance. BTW: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-4-Week-Releases If you guys check out comments/responses in the linux/FOSS communities, you'd see a lot of people mocking the ridicolous Chrome/Firefox versioning gimmicks so I'm not alone by far. (I redid this post as a new reply because I forgot to insert quote and wrote it in a too hurry the last time)

Here's a really good short Vulkan overview and comparison that should work as a TLDR for almost everyone around PC gaming to understand, as part of the Vulkan update in the recent Khronos Virtual Open House Korea February 2021: One big point that I never see mentioned by the ehm tech news, are many many other benefitial practical consequences that Vulkan brings to the end-users, namely patching satisfaction in terms of graphics bugs, graphics performance, and graphics optimization, because of a lot of responsibility being with the application, the developers can properly write a fix (with proper code, no driver hacks/magic) without having to wait for the GPU Manufacturer to release an updated GPU Driver and the users to reinstall the (most likely) whole GPU software suite. This is significant for DCS world, being considered a niche in relative terms, it rarely if ever gets any specific attention from the GPU manufacturers, at least publicly, and with Vulkan API DCS will break out of these shackels for good. What's driver magic? Well, when GPU manufacturers "fix" something, they don't actually fix anything in the game ofcourse, they essentially hack their drivers with their tricks and commands that the driver sends to the GPU at specific times when XYZ game is at this or that point, for one, among other things, this is also why such fixes are unreliable and are prone to side-effects, and specifically for when you run that specific game and they have to potentially do this for every single game in existance separately, so another thing was that GPU manufacturers were huge babysitters in the legacy APIs world and all of the industry had to rely on them, their driver team capabilities, their willingness, and probably time allotments and the money around that, a horrible state of affairs. Ususally when you see a GPU driver change notes about some "fix screen corruption, speedup, etc" that was never actual proper code, the way game devs can do it now with Vulkan API. Even if peak FPS isn't as big of a jump as some would expect in general, and initially it probably may not be in DCS as well, the new APIs have so many little and side benefits on so many levels that it is worth it, those are unfrotunately not as obvious to everyone, at least initially. However the blame now also goes to the game developers, so if a graphics bug or a performance issue is encountered, can't blame the GPU drivers that much anymore. When it comes to DCS the community should understand this is a major transition and that it may be a bit rough, but the sort of equalizer is this very fact that game developer can now fix and optimize at will ongoing and possibly faster, which means as times goes on it'll keep improving and reaching further heights, so it's not a good idea to make any conclusions when DCS first arrives with Vulkan mode. It also depends on what kind of state is the first beta release planned at, how far would the internal optimization go on before public beta, it's something that they will decide. Prediction the future evolution isn't that easy, for nonexistant OS versions and HW, etc, so only a backward look analysis is worth the effort after the fact. 52:20

Heh, I've been getting away with 8GB pagefile on top of 32GB ever since I installed DCS on freshly set up secondary machine. It gets tight in MP with caucasus, but playable just fine, RAM goes to 31 after a few hours, literally getting away with it, pagefile usage at that point is around 40% of that 8GB if the numbers in MSI Afterburner are to be believed (I'll double check with other methods next time) Syria in Multiplayer ... that's a no go, that'll have to wait for the new PC, which I've always seen as a 64GB RAM design and nothing less, already got em, but dang CPUs / GPUs are hard to get ... I'll wait also for the prices to normalize. Your crashes are suspicious if it's not low memory causing them.

One key thing I noticed compared to how I played singleplayer most of the time, is that MP missions tend to use almost the whole theater on every given map, even tho there may be some with lower amount of units and activity. While units definitely count because of the expensive aircraft livieries taking a lot of memory, but mainly because of the area, it takes more RAM/VRAM because the game has to load a lot more terrain textures, even tho your resources should only be tied to your position/camera and not others. I would also assume there's some extra memory needed for networking and multiplayer-sync (coherency), though I'm not sure how much, among other things. Perhaps it also depends on amount of players and their variation of liveries used, all of those liveries for all player and AI aircraft have to be in RAM at some point, hopefully they're not all loaded at all times when you're not looking at them but they could be for precisely the purpose of avoiding laggy texture pop-in. Most of the time I only use 1/4th of the map when playing my own missions in SP, and with only 1 player that's only 1 custom/additional livery, with AIs usually sharing those liveries which I hope doesn't duplicate the memory footprint of each one (just reference the same memory area I think) so you get lower usage there. The other thing is, which may even be more important is how much does the game need to keep cached in RAM/VRAM anyway, half of that is just cache to avoid disk reads, it doesn't actually need to be in RAM for the engine to work, technically there is a lot of room for improvement in terms of memory management in a lot of aspects in general for games, not just DCS world, this is a constant battle for game devs. Try lowering Preload Radius or Visibility Range in the options and see if that helps, I think it should. But your issue may be different I think you should create your own thread.

Oh I didn't knew that, would make great sense since OpenXR is also from Khronos like Vulkan which probably has more developer crossover and experience in the community as well as compatability familiarity that can come helpful. I would coincide this with the Vulkan API renderer for DCS, that together could make a good splash for VR users, it would also make sense from usability for these major changes to coincide so there's less major changes to the configuration and tweaking process for VR users. Once Vulkan renderer comes, VR may work differently and old tweaks/config may not work anymore, making users to re-figure out the optimal process, OpenXR support may produce this same effect, but if they both come together along with other changes/improvements, then it might be one less change of procedure for users, or perhaps much lesser of a procedure overall because the whole thing would skip ahead to a better implementation that would work better out of the box, potentially sparing a lot of back-and-forth within the community. ...... at the expense of potentially delayed release and more waiting haha

Reserved.

Hello This is something I noticed back in Q1-2 2020 but haven't had the chance to report about it. I came back to focus on DCS again now (tho not quite yet with a new PC as I hoped) so I would like to finish reporting this ASAP, even tho this could have been fixed for 2.7 by now or would have been noticed during the coming multi-threading update anyway. Initial Report Session, DCS version 2.5.6.60966 - February 2021 Straight to the meat and potatoes, the videos pretty much show most of it and may be somewhat self explanatory, thought I will put an effort to give it more context and point out some of the sections of these videos. I chose not to edit or transcode these videos. These uploads are straight from OBS Recorder. The quality on streaming sites is simply inadequate for text clarity that is required here. In order to record these videos without a hardware capture device I had no chance but to adjust the CPU affinity, this may skew the DCS behavior slightly, namely in the terrain asset loader threads being slower, exaggerating some delays, however performance testing of this part of DCS is not the focus in this case. I assure that this suspected bug is present in normal default CPU affinity and I've been tracking it for at least a year. Made on the PC2-2021 system as described in my signature and DXDIAG below. VIDEO RECORDING PART 1 (~ 8.5 GB) - https://mega.nz/file/vDYSBDiQ#VkWBRQ3J4Zh2DWhq1VLhd5_NbvoZ9IJ973f3ZjB2ePc VIDEO RECORDING PART 2 (~ 7.5 GB) - https://mega.nz/file/2eRj3SgS#ZWW00--4TmXqBhX8FWNb_hNiQs-pAq574TfkLsdp8Lw VIDEO RECORDING PART 3 (~ 90 MB) - https://mega.nz/file/OT4RCIzB#EsWYqCO8u9ORNhTnZvFp7ztaIiaw0uXRTOVj8gjAXT4 VIDEO RECORDING PART 4 (~ 4.3 GB) - https://mega.nz/file/XbRTwQJA#mO9BLl0lsssyiRBpxR1zgax0SBYZyuZFi5CbFTWf6go PART1 should be enough for most people from the community who may be interested in also seeing this, no need to download the rest. Testing on the video was done with F-18C as the sole aircraft on the Cacuasus map, in the offical Ready On The Ramp instant mission. The entire video portion of this report session has been recorded after a preceeding +5 hour Burn-In test, with the F/A-18C idling on the ground as spawned by default, while the Suspected Runaway Data Loader Thread using a steady 4.7% (in this case) CPU usage. Note that "CPU2" Graph on the MSI Afterburner overlay corresponds to the "CPU 1" by index, I forgot to relabel that to be consistend with zero-index labeling. Videos Overview: PART1: Cacucasus normal testing plus some high-speed and free camera testing, you have to go pretty far to notice missing terrain when suspended. PART2: Cacucasus more high speed free camera testing plus suspended threads testing. PART4: Syria + Suspended threads testing. Other Notable Video Timestamps (minus the ones mentioned above): PART1 00:06:55 - Mission Restart - DCS Threading behavior when loading mission PART1 00:29:08 - Suspending the Suspected Runaway Data Loader Thread for the first time and testing usage of aircraft during, looking for any annomalies. PART1 Toward the end of the video I start using faster game speed to see behavior in such circumstances Side Issues: There are a few other unrelated bugs and performance issues seen on these recordings. For example, the FPS drop during loadout and rearming starting at 7:40 minute mark in PART 1 video. The longtime asset stutter when missile objects aren't preloaded at mission load and have to be read from disk when you fire the weapon for the first time, or once after a very long time (too), that moment is at the 17:20 mark in PART 1 video. And another half-sure case at the 30:50 mark where I didn't saw much CPU usage of the Data Loader Threads nor the disk read spike, so it may be some other reason behind rocket fire FPS drop or it may be another coinciential lag right that moment from the terrain stuff. (or another thread loading those rocket assets) Key behaviors of the Suspected Runaway Data Loader Thread: It is continiously using CPU resources when there are no assets to be processed/loaded. Is it responsible for any other functions? It's usage is highly dependant on where the camera is and where the camera is oriented(looking at) in relation to surface terrain and the sky. It's usage slowly diminishes as the camera moves toward open ocean. After some +60 Kilometers off the coast, it's CPU usage completely disappears. It's usage slowly increases once the camera returns over land, but still varies depending on camera's orientation as usual. It's suspected idle CPU usage disappears while in F10 View, with the gameplay continuing normally despite it's zero CPU usage. Suspending it does not prevent normal gameplay functions. If it was helping rendering the terrain, the game would probably freeze or be very glitchy, but it's not. Suspending it prevents certain dynamically loaded terrain data (surface geometry, textures) to NOT be loaded. Portions of the terrain become transparent and sea-level water is seen instead. The currently loaded terrain data remains intact. So if there is no active streaming, it's CPU usage should remain zero, as it is with the other dynamic asset loader threads. Suspending it also prevents DCS from existing mission and entering main menu, DCS will not freeze but wait, once this thread is awaken DCS continues normally. Please note that in general for Windows platform, TIDs (Thread ID Numbers) in the videos are process session specific, they are only good for identification in the same process sessison, at the time when I recorded the videos, I've since restarted DCS several times and even updated it by mistake. When DCS or any other Windows process is restarted the PID and TIDs change, so these numbers won't be the same across various screenshots I may post in this forum topic. Unfortunately, DCS, but like most programs, does not have threads labeled/named except the DCS Voice stuff a little bit. So for better identification of this Suspected Runaway Data Loader Thread it comes down to a combination of the time a thread is created, it's stack details and the way it behaves in terms of CPU usage as well as the behavior it produces when manually suspended. As of this DCS version, the Suspected Runaway Data Loader Thread is thread "7" by index, sorted by creation date. The sorting by CREATION DATE was the optimal choice in this case, it made sense for a lot of reasons. It is the sort type that Windows PerfCounter.dll also uses (something which took me some time to realize and was infact slowing me down in making this report sort of). So far from all my tests I haven't noticed the index changing with this sorting, so I think it is consistent and we can rely on for this forum Topic at least, until any changes come to the threading in DCS in the future ofcourse, which is just a matter of time. Also note that the camera movement speeds in PART4 are far beyond what would happen in practice when flying an aircraft. Coupled with the fact that I'm recording and have 2 CPUs reserved for that, probably creates and exaggerated idea of the lag/delays seen in that case. Normally these Data Loader Threads and storage devices may not go under such continious stress, but on the other hand this high-stress load can probably be replicated under realistic gameplay especially in Multiplayer with a lot of F2 or F11 View usage where these Data Loader Threads would get well saturated. With a modern 8-16 core CPU and a NVMe SSD, this kind of load would probably be totally unnoticable and wouldn't be any problem at all (but I'm not there yet), if it is a problem then I would speculate it's more up to DCS's optimiztations. Please note that due to the limitations of the system used, the behavior of the asset loaders in terms of delay and performance may be worse than what they would be, delays and some of the stuttering effects may be exaggerated, due to all of the DCS threads except the main one being forced onto CPU 1 (CPU 2 in-game) Please note the version discrepancy, as much as I tried to do my best on all the circumstances, this one failed me. The video filenames are labeled as DCS 2.5.6.60966 while the video's text has another older version, I apologize I have lost the track which of those 2 versions I actually used, I'm leaning toward .60966 because the text may have been created prior to me starting that session, but I believe those are very minor changes between the updates. Also, the non-video screenshots below have been created with version .61527.1. I simply updated by mistake twice, I wasn't going to until this topic was out. Additionally, the Data Loader Threads (the ones that start with "ucrtbase.dll" with corresponding CPU usage according to disk activity) aren't necessairly responsible for loading everything, the main thread still does some other things, including during the mission load procedure. I have yet to test if units are completely loaded on mission start even if they're on the other side of the map. It seems to me once the mission is loaded, suspending it does not affect any AI's and ground units, even tho the terrain under them may be missing. ---------------------------------------- Video Preview Screenshot - PART1 00:00:41 - Beginning on top of a +5hour Idle Burn-in Test ---------------------------------------- Video Preview Screenshot - PART1 00:06:31 - F2 view fully zoomed out looking down on the airfield ----------------------------------------- Video Preview Screenshot 3 - PART1 00:26:10 - Runaway Thread CPU Usage almost zero, measuring distance with ruler in F10 map ------------------------------------- Video Preview Screenshot 4 - PART4 00:22:44 - Syria Suspended Testing As you can see this is consistent across terrains, not just Caucasus, and the gameplay seems to work normally, the AI's work, except the terrain is missing which is what these threads are responsible for, if they're not doing anything with terrain loading, then they shoudn't be using any CPU in theory. And by the way if someones wondering, we're not over the ocean here in this case, this is a common thing with game engines that water spans the whole map and terrain seems to be simply overlaid ontop of it. This is many times seen when you encounter a bug and break the bounds of the playable area, clipping through can reveal water in a lot of games. That however may be different with DCS so it's not necessary ocean, the logic and engine components don't suddenly treat this area as an ocean. So even if the terrain isn't visible and you see water instead, the Runaway Thread behaves the same way as it does on terrain. This underground-water thing could also be a more of a visual thing anyway, for development purposes for example like easily seeing the sea level height. ------------------------- Threads overview in Process Hacker 3.0.3705: (DCS 2.5.6.61527.1) Threads overview in Nirsoft ProcessThreadsView 1.29: (DCS 2.5.6.61527.1) Nirsoft's utility for some reason reports the start address for all threads as "DCS.exe+0x19" making distinguishing between threads more difficult, but it gives a bit more info in it's Stack Data even tho that extra bit isn't any more useful in solving this. These 2 DCS threading overview screenshots have been made in the same session and roughly at the exact same moment in game state. It was the F-18C official Free Flight instant mission, paused above Batumi shortly after starting mission and clicking "Fly" button. Process Hacker Stack Information: (for what's it worth without properly debugging) I did some of my own extra analysis for my own curiosity sake which I think doesn't hurt if I share it, but it may not be anything that is relied upon when trying to fix this, I understand. These lines are output by ProcessHacker when clicking "Inspect" on our runaway thread at a given refresh. Each block is another refresh, this is not automatically refreshed by the program, things happen fast and I kept hitting refresh for some time until I got most of the combinations out (some combinations are very similar) The first "ntdll.dll!ZwWaitForSingleObject" block remains steady across refreshes when the thread takes low amount of CPU resources. The busier the thread is (WHILE NOT READING FROM DISK - GAME PAUSED / IDLE) the more prevalent the edCore.dll!mmfMemoryBlockPreload blocks of lines are. 0, ntdll.dll!ZwWaitForSingleObject+0x14 1, KernelBase.dll!WaitForSingleObjectEx+0x8e 2, edCore.dll!ed::this_thread::yield+0x2bb7 3, edCore.dll!ed::thread::_get_current_thread_id+0x58 4, ucrtbase.dll!configthreadlocale+0x92 5, kernel32.dll!BaseThreadInitThunk+0x14 6, ntdll.dll!RtlUserThreadStart+0x21 0, ntdll.dll!RtlQueryPerformanceCounter+0x5 1, edCore.dll!ED_get_ticks+0x63 2, edCore.dll!ED_get_time+0x9 3, edterrainGraphics41.dll!edtg41::TerrainRenderable::dumpRenderItem+0x562b3 4, edCore.dll!ed::this_thread::yield+0x2cc0 5, edCore.dll!ed::thread::_get_current_thread_id+0x58 6, ucrtbase.dll!configthreadlocale+0x92 7, kernel32.dll!BaseThreadInitThunk+0x14 8, ntdll.dll!RtlUserThreadStart+0x21 0, edCore.dll!mmfMemoryBlockPreload+0x4d 1, edterrain4.dll!landscape5::Surface5File::Square::preload+0xc8 2, edterrainGraphics41.dll!edtg41::TerrainRenderable::dumpRenderItem+0x562ad 3, edCore.dll!ed::this_thread::yield+0x2cc0 4, edCore.dll!ed::thread::_get_current_thread_id+0x58 5, ucrtbase.dll!configthreadlocale+0x92 6, kernel32.dll!BaseThreadInitThunk+0x14 7, ntdll.dll!RtlUserThreadStart+0x21 0, edCore.dll!mmfMemoryBlockPreload+0x7b 1, edterrain4.dll!landscape4::GeometrySource::preload+0x76 2, edterrain4.dll!landscape5::Surface5File::Square::preload+0x6c 3, edterrainGraphics41.dll!edtg41::TerrainRenderable::dumpRenderItem+0x562ad 4, edCore.dll!ed::this_thread::yield+0x2cc0 5, edCore.dll!ed::thread::_get_current_thread_id+0x58 6, ucrtbase.dll!configthreadlocale+0x92 7, kernel32.dll!BaseThreadInitThunk+0x14 8, ntdll.dll!RtlUserThreadStart+0x21 0, edCore.dll!mmfMemoryBlockPreload+0x4d 1, edterrain4.dll!landscape4::GeometrySource::preload+0x76 2, edterrain4.dll!landscape5::Surface5File::Square::preload+0x88 3, edterrainGraphics41.dll!edtg41::TerrainRenderable::dumpRenderItem+0x562ad 4, edCore.dll!ed::this_thread::yield+0x2cc0 5, edCore.dll!ed::thread::_get_current_thread_id+0x58 6, ucrtbase.dll!configthreadlocale+0x92 7, kernel32.dll!BaseThreadInitThunk+0x14 8, ntdll.dll!RtlUserThreadStart+0x21 0, edCore.dll!mmfMemoryBlockPreload+0x4d 1, edterrain4.dll!landscape4::GeometrySource::preload+0x76 2, edterrain4.dll!landscape5::Surface5File::Square::preload+0x6c 3, edterrainGraphics41.dll!edtg41::TerrainRenderable::dumpRenderItem+0x562ad 4, edCore.dll!ed::this_thread::yield+0x2cc0 5, edCore.dll!ed::thread::_get_current_thread_id+0x58 6, ucrtbase.dll!configthreadlocale+0x92 7, kernel32.dll!BaseThreadInitThunk+0x14 8, ntdll.dll!RtlUserThreadStart+0x21 ------------------------------ I've looked at the threading behavior in the Mission Editor as well for comparison, but didn't record/snap any of that because there is no suspected idle CPU usage there from this thread. The 4-5 loader threads work as expected when you move the view around to load new map/clipmap data. ------------------------------ DXDIAG: (comments in brackets []) And as a reminder again, mistake on the videos, that the "CPU2" Usage Graph on the MSI Overlay is infact CPU1 by index. MSI afterburner does not use zero index for labeling CPUs by default, starts with 1.

EDIT: Too hurry post, rewrote this post below in a new reply.

Personally, I'd expect much more from a 3.0 than just Vulkan API and multi-threading, but it could be just me being used to slow paced versioning where the first number really means something. For 3.0 I'd expect changes across the board and particularly to those side and smaller or lower level things, GUI improvements, replay track improvements, updating a lot of the underlying legacy code, various optimizations, filesystem structure changes, file format changes that break compatability are best done when transitioning to a major new version, various config systems, the way things work in a number of ways that introudce a visible change the way user has to do it is best done on such occasion, so you'd want to pile in as much as possible of the smaller but handy stuff so that this kind of stuff isn't spread across when things are suppose to settle down in this regard, becuase many of such smaller things usually aren't important enough to warrant change/improvement because of the inconvenience it would cause to the user but also because it's simply low priority. A lot of low-priority but also low-effort required stuff that has ammased in a previous version is best to work out in the next big one, that's at least my logic. Another thing is convenience stuff that isn't necessairly improving any technical, but it is improving clarity and quality of life kinda from a cosmetic and maintenance point of view, some things also help developer ease of management and less confusion is a good enough reason as well, that all counts to development efficiency, faster and less error prone patches. I forgot refactoring (renaming things), this is a great way to also do this to lable things and change things up to make more sense as necessary. Look at it as a major janitor cleanup, you kinda make even the little things extra attention just so you get all out of the way and sorted out and don't have to worry about it too much for the next whole cycle even. Because it's the worst thing when some little thing spoils the moment when you're so excited for the big new beef steak, you don't want some spoiled sauce to ruin the show there, or some bad aftertaste from the wrong kind of spice.