Worrazen

Pretty much the only thing keeping history alive, that's one of the safety nets I was hoping on (besides private collections, museums) and this confirms it (althought it's nothing new, but new to me), these non-upgrade-worthy ones are the ones ED needs to try get some data/deals on, Russian govt could be less sensetive about the old versions after these upgrades as they move away from active service, hopefully something shifts. The big deal idea is still on, record the data while things still fly and are alive, for future when it's more okay and declassified to release things .... the most optimal thing is to just get special deal so it can be developed ahead of declassification. I's not arm twisting, it's that there may be a solution both parties would agree on but is not apparent to one or both of them and it may be all about just figuring it out what those terms are, it could just be as simple as giving one the idea "oh we could do this -- oh yeah that may work" that's the kind of scenarions I have playing in my head, so it feels a pity if stuff is denied based on sort of cheap reasons like this, okay another one of my russian-fighters-speculation, but I already said most of it weeks/months ago, so this post is just 4-5 lines long, lovely.

https://www.militarytimes.com/news/2019/06/11/why-it-isnt-weird-for-russian-sailors-to-sunbath-shirtless-on-deck-while-confronting-a-us-cruiser/ :megalol: Lauhging just about the article and a news piece in general, as I didn't knew they do this at all ... but a collision is still a serious matter. Anyway the practice of catching some sun whenever's the opportunity is indeed wise as it is vital part of health https://en.wikipedia.org/wiki/Cholecalciferol - just don't overdo it, over than 1 hour at noon is overkill and it's only damaging after that. EDIT: I actually thought of putting this in the offtopic section, mistake.

From one of the video comments. One thing you all need to keep in mind, these videos are indeed just excerpts, not full videos, just a reminder to those who may not think about this.

It's possible to switch branches on the same install apparently, thought I didn't bother with it yet so I'm not sure what file/entry you have to change. MAC being a separate install and not a DCS module was part of that compromise with the DCS community I believe, I wasn't that paying attention to that area the peak of those discussions happened, so I don't know in detail. These things may be removed once MAC releases, or once the testing ends, would make sense yes. Speaking about removal ... what about Game Mode and Game-Mode controls in the options, would that all be removed from DCS and added/integrated/morphed to MAC ? I don't have a particular opinion, just asking. Would make sense tho, would make it easier to maintain DCS if there's less modes and combination to worry about, for example.

No that's for updating only without launching. Switching branches is something else, I'm not in such a hurry so I don't bother with OB, so I'm not sure what is the way. (not that I don't want to help test, but I'm a bit busier with other stuff these days)

Actually .. I went back to my old threads now https://forums.eagle.ru/showthread.php?t=201530&page=9 and I think I remember now there was one thing which could have put a question mark on the whole thing, because one thing, I did mostly barebone scans/tests where nothing was happening in the game, I don't know why I didn't figure out at the time to actually test multi-threading you need to put the whole thing under stress so all parts of the engine are working something for those minor threads to even show up on the scans. It's time for another go, and I want to compare 2.5.4 vs 2.5.5 anyway so I'm redoing the whole WPA stuff right now while I'm still on 2.5.4, I already got the latest Win10 ADK version installed (which includes WPT (which includes WPR/WPA ..etc)), this time I'm getting more educated about WPA, which is the analyzer you see with all the graphs and that's where the meat of it is, actually knowing how to first use it correctly to display the correct data in a correct way that for this type of case and then to interpret that correctly, to make sure whatever I post is going to be more accurate. Not saying that stuff didn't hold true, but I think there could have been DCS improvements since then.

Initially posted to the VR performance improvement thread .. but fits here better. Depends on the context, I didn't happen to focus on VR-specific stuff, but a small and easy to fix thing in code can mean huge things in practice, if any of you are following Dolphin-emu progress reports such cases are documented time and time again ... optimization is a big deal. About the impact of LABELS: Stable 2.5.4 (I'm Stable-only these days) (is each of the labels it's separate draw call?) Those could be draw call (CPU) related, something that might have been improved too even without the need of Vulkan API. Same thing for the trees. The engine may be processing multiple trees more efficiently. As in this example below, on the one hand it's not only about the API, if an implementation (code) of the graphics engine lacks optimizations it doesn't help if a cool new API is used. DCS may had some of those improvements in 2.5.5 However on the other hand, you can see how massive the improvement can be when API features fundamentally better capabilities, not only does each draw calls cost much less on Vulkan API, it has the features to do things in one draw call that previous APIs cannot, so to answer the question, rumors of +50% increases MAY NOT BE SO FAR FETCHED. And the bigger question is, if +50% with just existing implementation improvements, what about the improvements with the new API .... so there you go :)

Depends on the context, I didn't happen to focus on VR-specific stuff, but a small and easy to fix thing in code can mean huge things in practice, if any of you are following Dolphin-emu progress reports such cases are documented time and time again ... optimization is a big deal. About the impact of LABELS: Stable 2.5.4 (I'm Stable-only these days) Those could be draw call (CPU) related, something that might have been improved too even without the need of Vulkan API. Same thing for the trees. The engine may be processing multiple trees more efficiently. As in this example below, on the one hand it's not only about the API, if an implementation (code) of the graphics engine lacks optimizations it doesn't help if a cool new API is used. DCS may had some of those improvements in 2.5.5 However on the other hand, you can see how massive the improvement can be when API features fundamentally better capabilities, not only does each draw calls cost much less on Vulkan API, it has the features to do things in one draw call that previous APIs cannot, so to answer the question, rumors of +50% increases MAY NOT BE SO FAR FETCHED. And the bigger question is, if +50% with just existing implementation improvements, what about the improvements with the new API .... so there you go :)

There are major ones that could be separated. Mission management (triggers, ATC, F10 view and icons) and AI, can't think of more right now but I'm sure there's some misc stuff. That would take some 20% off the main thread, IMO. I doubt AI is deeply integraded into physics simulation, even if it is, for some reason, it can be spunned off, those two things shouldn't need to rely on each-other.

I recommend cleaning up the driver's and DCS's shader cache after such a big update which touches graphics, to avoid glitches.

When you look at city that is draw call stuttering and driver overhead, this and other such cases (tons of trees) is the whole reason Vulkan API is being developed, because it's such a stupid issue that should have been fixed by the computer industry ages ago. 4GB of VRAM kinda won't be enough, stuff takes around 4-6, it goes up if you do more action and units (liveries) Also graphics memory leak or memory hogging fix (I tend to call it "hogging" when it's not leaking by it self) recently may have also affected the use of VRAM in normal situations so it could be potentially lower requirement, we'll see.

That's a visual phenomenon/illusion, it's due to combination of thread bouncing and slow response rate of the presentation (task manager) of what the CPU is doing. Those two threads are bouncing around multiple CPU cores (usually 2, sometimes third) at a very high rate giving the impression of "both cores doing some good work accelerating that game" but it's all a, when one core is working the other one is doing precisely nothing It's tricky anyway because if the graphs were in real-time it would be so fast, too fast for human eyes to discern anyway. Try using some other utility or at least set the task manager refresh rate/update speed to High This is however NOT DCS fault, this thread bouncing thing is how things for all computers/software unless the OS/FW/HW can be instructed to specifically not bounce through "thread affinity" but I'm not sure how that sticks yet. So I found that this thread bouncing is called "load balancing" in various PR and hardware enthusiast reviews, I didn't go to the bottom of this yet what exactly is the benefit myself but from all the various sources we can be certain it is not performance, if it is it's some benchmark that doesn't matter in practice, it is more likely about VRM/Power stuff, or simply spreading the load off that one particular CPU core isn't as wearied down, just like SSDs spread the load evenly across cells, but if that's an issue in CPUs at all is another question. And DCS is a quite a physics/math simulator, simulation cannot be easily multi-threaded, some parts of DCS that arent tied with simulation that are currently on the main thread could still be offloaded to yet another dedicated thread just like audio is, but you will probably always have one thread that takes the most beef and will bottleneck the whole simulator.

That's normal, it's usually around 19GB for me unless I do a lot of stuff it does get up to 23 also and depends on how many big-livery aircraft you viewed or loaded up, DCS would optimally need a lot more RAM than this, but it is able to keep it down. While 32 GB RAM is optimal for not having to close down browsers and other stuff but 24 GB should work fine too, it's on the edge tho, that's how I have seen it behave. There was a graphics memory leak fix in the recent OB patch, it might be the one I reported, still, I think it won't drastically lower the RAM consumption on normal play, but I can't test it yet because I'm on Stable branch only.

The updater unpacks to a temporary location which needs an additional step to actually install, so 3 steps in total, I haven't yet figured out the technical reason for not unpack-installing directly. 1 download 2 unpack (same path as download dir) 3 install (move unpacked to DCS) So every update takes ~30% longer than it could. If this is needed, to speed it up, I suggested separating the download and unpack directory so you could specify a different storage device of equal specs or more which would double the speed or more for the unpacking process. The unpack and install part are going half the speed they could if you don't specify another storage device in a config file, which is the default. I didn't include hardlinks, because that external, has nothing to do with DCS, but you can probably do anything with that like I mentioned.

Anyhow the type of community here, while possible to be online, some don't prefer to be living in densly populated areas or just take long hiatus every now and then, I think it's not unreasonable to ask to support such a feature officially in some way. If I could afford I'd get the heck out of the city to some refreshing hills for a whole month or two, RIGHT NOW! And for account/paid module validation don't need a fast internet, just a ping with the satellite link or something, once in a while, besides I wouldn't be gaming all day/week/month when I'd be in the wild anyway, so a 3 day offline grace period seems enough already. The whole always-online thing has it's drawbacks: https://www.fastcompany.com/90358396/that-major-google-outage-meant-some-nest-users-couldnt-unlock-doors-or-use-the-ac

That's one way of doing it, less optimal, the install may not be as proper and may have glitches with the updater but if it plays it's probably a non-issue ... however you'd need a 200 GB USB or SD card if you're big into DCS. Not sure if the modules on the host PC would need to be authorized or not tho, otherwise you wouldn't get any updates for those so it makes it worthless, but I think not, the updates should work. It's worth trying first moving the whole DCS install on the PC to a USB stick, taking the USB stick to the other location, don't start DCS just run the updater with "update" command line option so that it never launches DCS at the end of the update, so it'll see as "you have installed these and these modules and here's an update" hopefully. Now you bring it back to the cabin, and overwrite the stuff on the computer with the USB ... it'll ofcourse automatically only transfer the changed files and skip the rest so it shouldn't need to transfer everything, if you do it right.

I know it'll take longer but I agree with this way, proper FLIR rendering may be a good thing to have to actually properly experience the AN/ASQ-228 ATFLIR pod, so delay it and possibly have both coincide and release at the same time, and until then to ease the wait let's first have the AN/AAQ-28 Litening pod, and also makes the F/A-18C module more feature rich in the end.

It could easily work with the below method ... there's no actual patch file having to be created or any setup wizard. For minimal technical changes to be done with the patching system, all the updater needs is to see a USB stick that has the same files a remote http or bittorrent. For minimal maintenance, this wouldn't need any infrastructure, it would use the same, all you'd need is preferrably a separate utility (or a version of the updater, to do it on a PC without DCS) that would work as the updater does but it would just download and dump latest update onto a USB memory stick. So I'm not sure if DCS update infrastructure retain older version for public download, so whatever version you have in the months being in the wilderness, when you get to a checkpoint you'd download the latest to the USB stick, and that's it. The updater on DCS side will just need to add support to take data from an offline source, that's the majority of the work, and it shouldn't be that of a chore.

[REPORTED] Memory leak and crash when viewing up high Crash report was automatically sent, I thought first it was on my end because I used a really big mission and had browsers opened. Looks like GrimReapers also experienced a lag in that same spot in one of the recent DCS CA Tutorial videos.

I always keep forgetting setting some unit property (chaff, flare, fuel, orbit, ROE, alert state) when copy pasting and there doesn't seem to be any way to quickly apply a property to all units of same type, coalition, or group, it's extremely impractical doing it for every single unit. Can it be done with custom scripts? I'm not an expert on ME by far. At least if there was a button to clone the current unit config to all units in the group. But I do use a lot of units which can only be individuals, no group. Like AWACS, Tankers, big planes, so it's a half fix.

I bought it right now to support them support VR so you can buy it :thumbup: I had delayed CA for a long time, avoding to buy too much too early, I was planning to buy something this month, but didn't know what, the Grim Reapers CA tutorial's made me choose it. But I wouldn't be able to get VR for quite some time, as I need resources for something else (and probably the core of a new PC in a year or so), so my votes go to upgrading CA in general.

It says "It is import to know" instead of "important"

It's lovely but to early for that. The only thing ED can do is prepare infrastructurally for that transition abit ahead of time to have less/easier work later.

WOOOHOOO! This is what I'm talking about, this is what DCS depends most upon, single-thread performance, IPC lift! I had many posts talking how the computing went away from single-core performance, away from Desktop, but AMD just pulled out the BFG and delivered a totally amazing presentation (with all the jokes) unlike any kind before. This is what is recommended for DCS players, thankfully AMD did not left single-core performance behind, infact it's the core focus, this is very exiting time for the sim community!!! Even if the ST performance will now be on par with Intel's peaks, or slightly better even, so it's not like DCS players couldn't do this before if they chose Intel and had the budget, but it kickstarts this horse race again around IPC in general, the ST performance that's largely been lagging behind.

DCS needs a lot more VRAM than most GPU's have, all the terrain textures plus all the resource hoggy liveries (but that's fine, that's the nature of them), that's why a lot of it has to be offloaded RAM, combined with all the stuff on the RAM anyway. 16GB of RAM is not enough anymore, 32GB is optimal, 24GB Minimum. 16GB you're asking for problems. However, there's one big thing, DCS doesn't cleanup what it doesn't need, not that that's bad, it keeps it cached for faster access just like I suggested years back, but sometimes too much so it starts going into the pagefile, you can see this happening in Encyclopedia, it will not clean anything when you're viewing liveries/models there, if you keep going it will eventually run out and crash or crash your PC.