Worrazen

I have just significantly rewrote this thread for far more clarity on what my idea was and how I understood the newsletter. I also removed the part that's way too speculative and forward looking about the modularity of cooperative development(breaking map making down to individual components), which really wasn't the main purpose of the topic but only as an additional possibility that I could talk about later or elsewhere, and ofcourse as with any approach there's a set of tradeoffs and this can have a lot of downsides and challenges to be practical for the developer as for the user side. Replies: @cfrag 1a: Yes, the curvature should not have a major impact on average gameplay in a small battle zone. 1b: I suspect there should be measurable differences in artillery ranges already, not to mention long-range stuff. For this purpose I weant and did some more research and found a promising quora post on this exact question(just using bullets instead of artillery shells): Which reminded me when we're talking about curvature, it's not just surface curvature but also curvature of the gravity as well that you suppose to account for. https://www.quora.com/How-far-does-a-bullet-have-to-travel-before-the-curvature-of-the-earth-effects-it-trajectory So if this test plot above is watertight, a 5.5 meter difference at ~1.4 km already is significant and measurable, that's easily the difference between a direct hit or a complete miss (excluding splash damage/AoE for appropriate weapons) ... but after a discussion with some math/physics people and my own analysis, it will indeed not have that of a major effect on gameplay because: Spherical conditions would persist for a session and even across sessions (let's ignore the continued availability of flat legacy terrains for now), while wind and temperature can change and will change quickly (if it's change/effects would be simulated for artillery shells and other projectiles) Everything would ofcourse support the spherical model and would show proper distances/amounts, the sensors, binoculars, artifical helpers (Combined Arms) therefore for example your ranging intel would give you a number which would already be adjusted for curvature, the same way it gives you numbers based for flat surface right now, so you wouldn't need to adjust it for curvature yourself and re-acquire the gameplay skills. 1c: However curvature of the surface and gravity is one thing, there are others. The biggest one may therefore be circumnavigation-ability. Though speaking about circumnavigation, there should be an ability to limit the playable area to a zone/radius as a dedicated server or mission scenario rule (and limit the dynamic campaign engine to it), where the goal would be to focus example to closely or loosely replicate a historic scenario and have the things happening outside navigatable zones scripted to simulate for example reinforcements and other things. There aren't just strict gameplay in-the-cockpit factors, but convenience factors at large, for sessions, servers, etc, you could have the ability to dynamically change playable area, expand or shrink it, in the same session, adding flexibility to server admins, that would avoid mission reloads, server restarts and reconfigurations. That is the real broad benefit of having one big spherical map. Yes this will take disk space if you'd choose to install everything in high-quality, but that's what it takes to replicate reality and have these conveniences. A 2 terabyte NVMe SSD for DCS shouldn't be something surprising. It shouldn't be slow or buggy, that wouldn't be the spherical map's fault, that's all memory management responsibility, it just needs proper programming to dynamically stream surface assets like it's already doing, just even more optimized and better.

[As of 5th May 2023 this topic has been updated signficantly (accuracy, clarity, overview), thanks also to some of the early posters for their additional input] Hello This is a proposition regarding the recently officially announced "Spherical Earth Map" or in other names and descriptions the community and developers have been using, to name a few: Whole World Map 3D Sphere Map Proper Globe Terrain ... and various other combinations Planet Earth is technically an "oblate spheroid" and the DCS 3D whole world curvature-featuring map technology has to simulate our Earth's geometry for enhanced realism. This opens the possibility for major gameplay and other benefits across the board for the DCS ecosystem. Because this feature most likely affects many other components of the sim, it requires changes to those components as well I would suspect, most definitely physics (gravity), weather (clouds have to wrap around as well), and since coordinate system is something many things depend upon, those things may need adjustments to function correctly. So it is not just a question of map technology, with such a profound change it ofcourse means that existing terrains most likely cannot be simply transferred ontop of this technology, so it wouldn't come as a core update to existing terrains and turn them curved. Quoted from the official newsletter: Analysis of the newsletter: The way it is explained in the recent newsletter, is a bit different from what some of us imagined this technology would be implemented and introduced as, and how would it actually stand in comparison with traditional flat terrains. - From the first sentence it seems that the technology behind the spherical Earth map is more or less complete, but it does not end confirming whether that is necessairly 100%, but non-the-less this is good news. If the technology is more or less complete, it should be entirely technically possible to release a test version with a minimal set of visuals and assets, at least for the closed-beta testing programme. - The second statement has many parts to it which I will address individually. First it goes to indicate that the next major task at hand is to actually (fully?) populate this empty sphere earth model with some useful textures, buildings, environment for a worthwhile experience. But wait, it doesn't actually say that, it just says that the sphere map is based on the "current day" scenario/setting, but that's how our the common sense logic would tell us when we put these words together with the previous statement. This "current day" is, as I understand it, indicating that they're populating the map with assets (developing and placing the content/roads/structures/landscape) which happens to be in the current day timeline esthetics and design-wise. I say that if they have the ability and stability of the core technology to start populating it, than the core sphere technology most likely has to be finalized, for them to feel comfortable (worthwhile) doing it. To populate the whole world (Earth 1:1 scale) should be a massive task and may take a considerable amount of more time and effort. The time aspect might be lesser if there have been many many more developers assigned and hired, with additional external help and/or with new advanced automated map creation tools. Despite this, and considering the last statement of the news letter, a 2023 release doesn't seem likely. The most important question: Do DCS players really need the whole Earth map to be fully populated and highly-detailed at it's introduction? Would the players accept gradual expansion of the content of the spherical Earth map. - The next part explains that the spherical Earth map would come as an independent installation, leaving existing terrains intact and playable. What has been expected is now confirmed and proper. Due to the profound changes this technology introductes, it cannot be simply bolted ontop of existing terrains (or the other way around, the existing errains cannot be just pasted into a 3D sphere model). - Significantly, the second statement is worded in an odd way that blames the current day design theme/scenario/setting of the content of the new spherical Earth map to be somehow a limitation which prohibits other scenarios such as WW2 from supposably existing in a spherical Earth map, at all. This, no offense, makes no technical or practical sense at all, it's one of the points I have the biggest objection to. The sphere map technology must not be developed and implemented in such a way that creates hardcoded limitations to some kind of a specific scenario. I would really like to believe that this was a writing mistake of the newsletter and that this most likely isn't the case in the program code today. - Additionally the same statement also says .. "independent of ... future regional maps ...", In my opinion, flat terrains of today should be segregated as "Legacy flat maps" scheduled for future deprecation. DCS 3rd-party developers should be provided with tools and APIs to be able to create their own spherical maps/instances in addition to flat ones, irrespective of the scenario theme, setting, season or size of the intended populated/gameplay/textured zone. Additional Propositions: Spherical-s is the way to go - Multiple instances! I see no reason why there couldn't be multiple instances of a spherical Earth map, existing independently, without the need to necessairly provide a whole world high-detail coverage/experience. A user just wouldn't be able to run more than one at a time ofcourse, we're not talking about simultaneous instances, just like only one flat terrain module could be loaded up currently. The major point is ofcourse in the curvature that even the smaller regional spherical maps would benefit from. Just because the intended coverage area may be "small", it doesn't have to be limited to flatness. Such smaller-area-only(regional) spherical Earth maps would segregated/categorized away from the fully populated spherical Earth maps. Normally a user would expect to be able to travel freely and circumnavigate the sphere even on regional spherical maps, which is another major reason for such maps to also be spherical. However I would suspect that such kind of maps would need several special rules for AI's and Players alike due to most likely limited functionality outside fully populated areas, when operating outside the covered areas would affect gameplay in a negative way. For example other airfields could be disabled if they would infact exist as part of the core default spherical map. Map developers would build their regional (limited) spherical maps ontop of a base-level layer of minimaly acceptable visuals and terrain surfaces, outlines of land, shore, mountains, forrests, and other geological features, textures. The other reasons for a faster transition to spherical map technology is global weather, even regional maps would in that case benefit from this, which would avoid the need to maintain both flat and curved weather flavors, thus spending more effort trying to make the weather on flat terrains work as good as it would on the proper spherical version, should be avoided. Current flat maps in early development should review future planning and reconsider whether they should push for an earlier switch to spherical before commiting too much time and effort into the flat method. Common Curated Assimilated Sectorized Spherical Earth Map - This is actually that main idea how I imagined we could one day experience this technology in DCS. This particular map instance would be intended to contain assimilated/recycled/converted content from existing flat terrain modules, provided by it's developers if they hopefully wish to do so, therefore a "common" map. Additionally it could be regarded as a transitional map, separate from a fully fresh from-scratch map instance that ED (alone?) is already seemingly working on. The sphere model would be split into many standardized sectors of a grid, perhaps one of the standard GIS or military grids out there. Perhaps evenly splitting those sectors down into smaller ones which DCS would accept, for more map making and merging flexibility. All sectors would have unique identifier, those that are split from larger ones would preferrably bare some reference to it's parent before their own identifier. A sector would accept an asset package that's specifically built for it and it's size type. The asset package would, at least in this case let's not get too comlpex, contain a complete set of the terrain and all of it's features minus the core basics of the spherical map technology, which would all be the core spherical map technology responsibility managed by ED, thus alleviating 3rd-party developers from having to worry about physics, global weather, and other core and under-the-hood parts, allowing them to better focus on the actual map creation of the surface heightmap, ground features, objects and textures. So when a developer would choose to develop a sector or sectors intended for this common spherical Earth map, they would start from a different template and slightly different set of APIs and tools versus what they would if they would be trying to create their own whole fresh instance of a spherical map. The idea is for the users to be able to pick and choose which sector asset packages to buy, install and activate, depending on what they're interested in. Regional spherical maps could be sold as a set of multiple sectors. Perhaps optionally as a monolithic module of inseparable multiple sectors, without needing any special tooling to prevent extra effort dealing with possible sector boundry issues, by just locking multiple sectors artificially as a rule, disallowing users to try to fill in other (most likely incompatible, bug prone) sector asset packages replacing parts of this monolithic regional map. All or nothing. This is how these recycled flat terrains could initially be featured on this common spherical Earth map instance. The ability to have multiple sector asset packages per sector, whatever developer they're coming from, whatever the design theme/timeline/setting it is. Most significantly, enhancing cross-developer flexibility, redundancy avoidance and cooperation possibilities, allowing smaller map developers to contribute to the whole map without having to commit to large project timelines and resource requirements, but this isn't intended for this recycled map instance, but rather for the new fully-fresh from-scratch one that could and should also be in development for the future. Users should have the ability to switch between sector asset packages in-game, only required to reload the mission, not the game program. For that, new in-game user interface for map sector management would be created as part of DCS core, intended for users to activate-deactivate various sector asset packages, with a basic "F10"-ish minimap overview of the 3D sphere model where they could select and choose which installed assets packs would they like to enable on which sector. The buying and installing management would be added to the in-game Module Manager. Functioning global weather and fully dynamic seasons according to in-game date/time, so separate seasonal instances would be completely unnecessary. Developers should avoid creating traditional multiple season versions until that system and tooling for making and populating the spherical map with dynamic assets is actually functioning and provided by ED. However developers assets should be allowed to skip supporting dynamic seasons even if such support is already there and possible, because this would slow down the conversion of existing terrains for this map. This can come later (if at all for this transitional map) In that case there simply wouldn't be a change noticable whenever it starts snowing or whatever, the global weather and dynamic seasons engine could still operate in the background on their own like they would, affecting other possible minor things that do support them. Boundled with a core default basic layer of minimally acceptable visuals, a base-level asset package, containing what I mentioned already, low-detail (low dev time) land surfaces, shores, mountains, forrests, structures and textures ofcourse, for the full coverage of this spherical Earth map instance. These base-level visuals would function and be separated to sector asset packages, populating all of the sectors of the whole spherical Earth map by default when they're the only ones available, but they would be replaced completely once a "high-quality" (official but free, sold, 3rd-party) or another sector asset package is installed and available for use. "Curated" because it would most likely have to be merged together by the main DCS developers (ED) before being released/updated to the public as a fully independent map module. This is because, from my educated guessing, I am foreseeing possible technical and practical challenges when dealing with assets on or close to the sector boundaries, where content from different asset packages would meet, requring an extra process that would adjust/modify and ensure compatability for all of the asset packages that would be available for this map. This would be a problem mostly between asset packages from different developers. It's about the need for visuals to blend and linkage of logistics so that no sector boundry could be felt or be visible in the final game environment. For example: Rivers would have to flow seamlessly between borders (even if "flow" is only a visual (not physically simulated) effect) Civilian traffic would have to to drive seamlessly between borders, including waypoints and paths for Combined Arms. Trains would have to drive seamlessly between borders, and the signalling, scheduling, would all have to work. Textures, materials and objects would have to be properly aligned. What happens with assets that stand literally on top of a sector border? There might be thousands of structural assets that might land ontop of the sector boundaries. There is a possibility that this issue may have a chains or domino effect which would, for making one sector asset package compatible with the rest, require adjusting not just the immidiately adjacent sector asset packages, but perhaps others or many others as well, if long stretches of railway or other infrastructure routes would so require to function properly (when they would have a gameplay functionality and thus more complex logic that goes along with them > dynamic campaign) It may be necessary to rework the infrastructure/path/route system to actually support such modularity and sectorization. Without the additional ED step and merging process, this would need substantial cross-developer cooperation and compatability effort which may be less efficient for each and all third parties to do, not just with DCS, normally addons by 3rd-parties do not cooperate or share source data in such a way. With ED being responsible for properly merging all of the sectors, provided by different developers, this kind of approach might work but there could still be a need for advanced automated sector compatability tools and verification processes, because of the sheer amount of assets that there would be in the boundary regions, but also depending on the lower level systems and whether the idea of sectorization would be seriously attempted with other core components being built to better support it, alleviating the need for a complicated merging process and additional manual labor. The great question is, or rather the big goal should be, if after all this would work, whether it would be possible to give users the ability to switch between sectors without having to actually download and install a whole different version of this common map instance, just to replace that one sector. The system really has to be able to work like that, otherwise the installs could be huge and quickly impractical. The other solution is to simply have isolated sector asset packages (or a series of locked-combined sectors > "regional maps") where you wouldn't expect any content inside it to be functonal with any other sector asset package from a neighbouring sector. On the other hand, in this case the common assimilated map is intended for quickly getting the existing flat terrains together on a circumnavigatable sphere, almost it not all of these existing and perhaps soon to be released regional maps are actually far apart and do not touch closely, which would significantlly simplify the merging process because only the outer borders of the multi-sector map asset package would have to be addressed and in this case the touching asset packages wouldn't be from other "high-quality" asset packages, but from the pre-existing core base-level assets so it would be an even easier task at hand. ..because the core default base-level asset package layer would only feature a couple of main roads and railways, large city outlines and stations, a few structures and couple of airports/airfields and that's it, not that much to worry about connecting. In-house Spherical Earth Map - The separate independent spherical map instance with the "modern day" asset package that the DCS developers have apparently been creating fully fresh from-scratch for supposably the whole area of the spherical Earth map. And one day perhaps there may be a WW2 instance like this as well. Other: As mentioned, the flexibility and usefulness of this shift toward spherical maps, and merging of existing terrains into one salvaged spherical map, not perfect but a good start, might automatically alleviate some of the other problems that various community memebers have been expressing that do not necessairly have a direct relation to spherical modelling but to the way maps are sold.

@Spectre1986 1. Task Manager's CPU details isn't the best utility for determining which thread is on which core, it can be misleading. 2. Your theory does seem plausible because AMD put cache on only one CCD which is kinda meh tbh, but this is how are the beginnings of a new tech. But I wouldn't call it 100%, let's test and wait a bit before calling it. 3. This can actually be AMD's fault as well because it's them who put 3D cache on only one chip and so introducing this potential detriment in the first place, so it's their responsibility to make sure the workload they have intended to enhance is actually being enhanced correctly in daily user practice. Also it's up to AMD to negotiate with Microsoft on how to deal with these kind of CPU topology. It's up to the BIOS / AGESA / CPU firmware and Windows kernel to properly schedule these gaming threads. The application also has power to perhaps deal with it itself and perhaps try to override system behavior. 4. If process lasso, process explorer or system informer isn't working for you with affinity, then you can always go to System Configuration (msconfig) -> Boot -> Advanced Options -> Number of Processors -> X. and select the number of processors + logical and hope that it does count from the beginning and is standard to what we would expect, or do it in the BIOS if there's option there. So this would be a way to completely disable the other CCD without extra cache. You should do this to test this theory out anyway. While you're at it you could first disable HT/SMT as well and get the idea of performance with just 1 thread per physical core and without CCD2, and then with HT/SMT enabled and still without CCD2. EDIT: Seems like some people report DCS MT not starting if some CPU cores are disabled, well darn it, it should be DCS bug that has to be fixed first.

Quite a while ago the heads of ED talked about "New Rendergraph engine" ... so in the end it may be practially a whole new* engine with not just "multi-core optimizations" bolted on, but being built for multi-core AND Vulkan API in mind from scratch, I hope that's the case.

I have a lot more to say around this and CA and DCS in general, but I think this relates to my previous point. People have a wrong idea of what CA is about. Damage model in my opinion has nothing to do with CA. CA is just the ability for user control and piloting of more than just aircraft, GUI and associated functionality, that's what I thought and that's also what is said on the product page. For example In my experience I found the F10 Top Down Map RTS-Style view controls of various units and groups to be buggy, the way you have to click for giving move orders, left clict, right click, indications, the way orders get canceled, confirmed, stuck, some units don't move with the group, speed control being ignored, etc ... I think that's a lot more relevant and valid feedback for CA. So if Vehicle Damage Model is out of the scope of CA, then your feedback based on that argument is probably completely invalid. What I do not like in general is that in DCS there is still no clear separation of what level of simulation each unit is simulated in so it creates some confusion. Some units are arcadey, some are simple, advanced, professional. Plus there's no any kind of standard in any of these terms inside DCS, let alone the industry (not necessary, impractical, ..other reasons I can't remember the word), unfortunately standards also change as time progresses, so it's tough, maybe that's exactly why these monikers weren't set in stone in the past. I guess the encyclopedia would cover that separation, but I think it could be labeled or otherwise indicated in the ME, there could even be a category filter just for this purpose, but ofcourse not in-game. I don't have a 100% opinion on this because there could be some downsides and I would need to explore this more to figure it out.

I think what some people may not realize but would agree with that what is being said is what the next CA should be and not what the existing CA needs to be. Simply rewording and transforming all of these complaints into feedback and ideas for the next-gen CA would be much better and I think a next rewritten CA should come anyway in order to support and be well integrated with the "Dynamic Campaign" and other advancements, at least in areas that matter.

64GB all the way, worry about the speed and budget later, you'll save yourself so much hassle with checking if things are over the limit, pagefile and all that. Computers meant to use RAM, not pagefile of a HDD/SSD. EDIT: I'm talking about DCS in mind by the way, on a modern main PC, as PC support on a gaming platform I think should be around the game, not in general. Otherwise nevermind then. There's more appropriate places for general PC support, IDK why people don't look those up first.

And Intel's 13th-gen CPUs will be announced and released in early-mid fall, leaks from supply chain are already coming out, so yeah, timing is very important too, you want to wait just a few more weeks or a stretch and see and then jump on the latest, you might have to wait more a bit for time to compare and let things calm down initially, there could be some early bugs and stuff as usual, have a good comparison between the two, market availability and then you choose Besides DCS's problem is CPU and GPU optimization, which most definitely won't come before the new CPUs (or in the end of the year if it's a surprise), so the wait won't hurt you, the long-term investment is a better way with DCS, doing everything else but DCS would be a good investment, setting up the basics, your place, your PC room, desk, cabling, electricity, then the PC, installation, software, all the stuff around your setup so that when you fire it up, nothing else would be in the way and you can focus on DCS.

You won't make a mistake going AM5 with Ryzen 7000 as that is the next gen that's being introduced this year, and it truly is next gen, it's the introduction of the new AM5 socket for AMD, and AM5 will be there for at least 3-4 years (even tho they say 2024+) software can be optimized as time goes on and as DCS will get big optimizations in the future, your PC can suddenly become good enough if you think it won't ... yes, even your next gen beefy PC is not going to see some earthshattering DCS performance because simply DCS is a simulator and is inherently hungry, consumer hardware in terms of single-core performance is a total joke and that moore's law was broken ages ago, they're basically cheating with multi-core in a way to keep those graphs looking good, but your multiple cores can never work as if it was a gigantic single core. You could even wait for Intel's 13th gen but that's a wait until at least october if rumors are to be considered. The dillema is if you want to wait until october-november to see how Ryzen 7000 and Intel's 13th gen compare, but being on the latest and early adopter you have timing that's working against you. This is the first cycle of DDR5 RAM, prices of DDR5 are at their highest now that they'll probably be for most of the next cycles, RAM tends to see an increase at the end of the cycle too, so I can't say DDR5's price is the highest now, it could get higher 5 years from now but that's just scarcity that does it. Intel 13th Gen is going to add more E-Cores, so perhaps you might have more cores in total with Intel there, but that still remains to be seen if that'll be enough to go over AMD. With AMD's Ryzen 7000 series, all CPUs will get an integrated low-power GPU as part of the I/O core by default for maintenance, this means you can power up the PC without a dedicated GPU and do troubleshooting and maintenance, enough to use the web in a basic way. Since it's a GPU inside I/O core, it doesn't take away any beef from any CPU cores and is by amd NOT considered an APU and yes that makes sense. The earlier APU's from previous gens had to take a cut out of the CPU stuff for their GPU components, because they don't increase total space for extra GPU components, so an APU for the same level model would have lower CPU performance compared to their CPU-only brother. AMD Didn't announce yet what they want to do with desktop APUs for 7000 series, and rumors are AMD is trying to move away from the "APU" moniker, perhaps signaling APUs might become different ... maybe they'll actually start adding an extra dedicated GPU chiplet on without sacrificing any CPU performance versus existing CPU only models.

Good attempt, you shouldn't skimp on your first PC otherwise you'll start out with a wimper and you don't want that when trying out a new platform, and because you have little PC maintenance experience it's better to be safe than sorry, any issues with good but not good enough parts can get you expensive repairs or a headache if you try to fix thing yourself. But when buying any kind of PC hardware, in general, it's also the time context that's important, you have the wrong platform for this time, going Intel 12th gen now would probably be unwise, AMD's Zen4 Ryzen 7000 series are just around the corner, basically counting weeks. The AMD 7000 series CPU's are set to go well over Intel's 12th gen, don't hold my word, but this is what is being said, so any better single-core performance is good for DCS. I'm not sure about intel for what they plan with the chipsets and new CPUs, but with AMD it's already been announced you have the option to upgrade to a 3DVcache later that should again boost gaming performance (single-core) CPU: Wait for AMD 7700X or better Motherboard: AM5 platform boards are just starting to be announced, no need to go with the E(Extreme) versions chipsets. RAM: DO NOT GO BELOW 64GB!!! SSD: Those write/read speeds are "sequential transfer", the random and 4K are more important for general and OS main drive and usually significantly lower than what it says on the label. Sequential means if you copy and paste one big 1-10+ GB file ... but most of the time that's not how programs/games read/write. Pay attention to the controller a SSD has, some are just better than others, this requires reading in depth reviews, I'm out of the loop on these things these days. PSU: I have personal experience of many years and PSU is not something to skimp and I always go overboard with it, for a big build like yours. Do not be fooled by Wattage thinking it's enough, you never want a PSU to work at 100% of the rated load, 90% max, that ensures longevity and stable supply. Costlier PSUs also have better filtering and cleaning of electrical noises/harmonics and other bad things that will hurt longevity of your motherboard/ram/cpu and all of the other components. This one's probably good enough, but I personally have the platinum HX series myself. EDIT: Fixed PSU opinion confusion (old obsolete text removed)

Force redirect download chinese version of the map for all china IP's, or simply don't name the island in text, many options. ---------- Honestly, while emotional attachement may be the driver in people's preferences for a particular map, well it is, but the context matters, areas where wars happened aren't so ethusiastic about having a map to replay the war on, it's the trauma of war I guess, it's to be expected, but truly nobody knows the real reasons for lack of Crimea map, there may be many. So the people who are not affected by war trauma are going to be the biggest users of a map IMO. Someone across the world would have zero issues playing on any kind of side/faction on a Ukraine-map for example, it's not surprising, there's no emotional handicap, no emotional barrier. I'm not that eager to have a Balkan map just so I can ... do what, I have relatives across balkans, I don't exactly feel eager to drop virtual bombs down there, even if it's all defensive, so I could understand if this is one of the reason's for lack of Crimea. However, was there really a big need/justification for a Ukraine+Crimea region map for Flight Sims in the first place, in terms of historical battles in real-life ... WW2 maybe but that's it right? It might be now so the priorities could have changed this year, but the other reasons against it could have also strengthened. My primary interest for a Crimea map has pretty much been simply everything else but DCS related and outside of politics. Traveling, history and exploration, except that I did it virtually, couldn't afford to do it physically. I was fascinated by the consequences, massive economical prosperity of Crimea, massive road, railways and rebuilding projects, and that would make the map in DCS look cooler too. And I just like that some of the cultural, architectural and such pieces be recreated and represented virtually as a form of historical preservation (to varying degrees, DCS ofcourse doesn't focus on exactly that, but it is a contribution non-the-less in general) But this shift of reasons and priorities for DCS content was due to me spending less time with DCS due to other life stuff and lack of flight gear, the GPU shortage, etc so I guess I might not be the best person for having a good opinion here, especially the gameplay argument, whether Crimea with the lack of the northern grounds would actually improve the Caucasus map experience, or just a spawn area as mentioned. Also, is Crimea even part of "Caucasus" geographically ... I think not, well it's not like there's a rule of only the land of what the title says right ... (comparing to other maps and past common sense of no straight cut-offs), but in that case it's not actually missing anything heh.

Yeah false alarm, I was opening it in LibreOffice Draw which took 1.8GB RAM, I think because it loads the whole PDF as an editable document and fully caches it into RAM, not just quick view. Opening in Okular or Foxit PDF Viewer on Windows takes less than 100MB.

It does look like one yeah but, it open a page with a loading icon that spins forever and there's a small icon in right upper corner for download. It's Firefox for OpenSUSE (linux) Tumbleweed currently. ADD: Same thing happens on a much older Firefox on Windows 10

Btw, perhaps replacing the PDF download with a direct file link, the preview link right now tries to open the PDF which at this huge size and complexity it'll probably never do in-browser, or it'll take a lot of RAM and lag a lot.

Indeed, access to the airframe and/or cockpit would make it a lot more attractive because the 3D scanning can be imported into the 3D visual modelling software to speed up the process, taking less time and cost, and probably being more accurate than even what the blueprints would have explained.

Yeah there is room for improvement in garbage collection, but it's general problem due to programming it self, C++ is such a programming language that requires manual garbage collection, it has to be programmed in, every bit of it. Don't worry about the "Standby Memory" or "RAM Cache", that's not the memory that will cause crashing, this is kept intentionally uncleaned by the OS or applications so that the next reads are faster. It get confusing if you try to dig deeper, it's a lot more complicated and the terminology doesn't mean what you'd first think it means, and it isn't consistent across the back-ends and GUI which adds to the confusion. If you fire up something else it'll drop unnecessary things automatically (it has some kind of an algortightm and rules which things to dump first, but I don't know how that is determined). If you get an actual crash you should report it, and record it or screenshot it, preferrably have multiple diagnostic utilities opened (process explorer, process hacker, task manager memory) while taking the screenshot when it crashed, and any error messages DCS might show. For DirectStorage, it's only for newer HW with updated Win10 and Win11, you don't need to turn it off, but you can't enabled it on games that don't support it, the developers have to patch games to add DirectStorage support. Either way DirectStorage won't work at full speed on Windows 10.

https://www.khronos.org/events/vulkanised-webinar-february-2022

When we say "The Vulkan API" we don't actually mean the raw API code alone, perhaps we're all not really using these terms correctly perhaps, but I think everyone out there uses the term API to refer to the whole pipeline with the drivers and all, so saying "Xyz API" does this and that, I'm talking about the whole environment, not just the raw API code. I guess perhaps the proper term would be to referr to it: "In a Vulkan API based environment" or "In a Vulkan API based application", but that's a mouthful. When you run a Vulkan based application, or in Vulkan mode, it won't use the same drivers as it does in DX11 or DX12. DX11 and OpenGL drivers where by because of the API it self, they have a completely different approach and require a lot more overhead from the start, and weren't designed for multi-threading the graphics backend (the graphics code that runs on the CPU). Vulkan's approach uses a "thin" driver that apparently does far less things under the hood and under the developer's radar, therefore also far more predictable and transparent in the stuff that it does, this is why it's harder to develop because many responsibilities shift to the application. https://www.intel.com/content/www/us/en/developer/videos/introduction-to-the-vulkan-graphics-api.html https://www.intel.com/content/www/us/en/developer/articles/training/api-without-secrets-introduction-to-vulkan-part-1.html One of the other things why legacy high-level APIdrivers are so bloated and require more CPU is because they run validation at all times for all end-users, with Vulkan API validation is optional. --------------------------------- As of right now, disclaimer I'm not a real Vulkan API or C++ programmer for that matter, I'm more of an analyst of the developer resource circles, going over the documentation and indeed spending hours reading it sometimes, various presentations, I spent many hours on reading up on Vulkan over the years. I don't completely agree with the earlier posts that the standard Vulkan API implementation out of the box does nothing without multi-threading. So CPU bound situations should definitely get some kind of a boost even if DCS wouldn't be getting the extensive multi-core enhancements across the board. The thin driver would immediately demand much less CPU resources by default, AFAIK. I can't find those slides right now but I distinctly remember that from the early presentations (That could have been Mantle API slides, but it should still apply to Vulkan). We would need a specific apple-to-apple comparison of an example Vulkan API implementation in single-threaded mode to a DX11 (ST) implmentation and compare just the driver overheads, which is what 3DMark "API Overhead" test might be all about. As far as games and sims go, who would bother going all the way to switch or add Vulkan API based rendering engine only to remain in single-threaded mode, so yeah, combining all of these things gets you some serious results in the end and it is very welcome that ED is taking a wholesome approach, multi-threading not only the graphics backend, but pretty much all the other major DCS components, and this is where a lot of the CPU improvements are. However as far as I know, again the cost of each draw-call is fundamentally much smaller with Vulkan API environment "it self", so hypothetically if you had all of this application multi-threading and kept "using" DX11 level of driver overhead and all of it's behaviors minus having that driver overhead stuck on one thread, maybe you could push much higher draw calls than standard DX11, but all of the CPU cores would get busier and thus less room to add other CPU work that the rest of the application could use. ----------------------------------- However, It remains to be seen to how much ED managed to split the various serial type of workloads, how much can be multi-threaded. I hope the AI logic calculations of each AI unit could have it's own thread or even threads, tho if they are expected to use very little CPU on their own for most of any kind of busy session, perhaps that wouldn't be necessary and a Unit Group could be it's own thread for example. That would get tricky when you have 100 units in one Unit Group tho, but I won't speculate on this right now, the approach could be totally different under the hood that takes care of my concerns here, dynamically spawning threads where needed, packing smaller jobs into threads, etc. Let's remember that many simulation type calculations cannot be parallelized, they will remain serial workloads even after all of the DCS multicore enhancements, a stream of calculations where the next one depends on the result of the previous one. Stuff like missile tracking, ballistic trajectory calculation and physics I think are serial and will remain serial workloads, but I suppose they don't all have to be on the same thread right, each weapon is independent and their tracking and physics simulation calculations could, but then there's the question of sync with the core engine for consistency and multi-player, so it's tricky how much of this can be independent. There surely would still need to be a kind of parent/main thread that connects all of this together otherwise you wouldn't have a working game, but it would have far less workload to do. I would appreciate if future reports would cover these questions as well. Would I be able to spawn 300x S-300 AA batteries and each unit would have it's own thread as per standard, then each missile launched would have it's own thread as well. Would that even matter in the end or would the engine always stall on something else first? But all of these small things could make a difference for really getting to be able to support those large dedicated server use cases, with a 128-core CPU and as much threading as possible maybe you could squeeze things out for a big mission, but then there are other things that are/would be parallelizable but may be too minor to make any difference in any kind of large scale mission, which would make that setup an overkill.

Except Web is one hell of a platform to maintain, browsers keep changing things at a fast rate, generally Web and it's scripts are incredibly unreliable, depends on the skills and the environments, major sites may have no issues, simple sites either, but it's a very volatile environment. If it's all simple html then I guess it might work, but Mission Editor is going to go 3D, and that would mean trying to run DCS inside Browser, nah, possible, but it would be very impractical and inefficient for ED to deal with that on top of everything they have going on in terms of DCS codebase, legacy spaghetti code and stuff.

I hope the modern displays/computer have an option for general font color, I still like green better over white for now.

Appreciate the dirt airfields, that kind of auxiliary / emergency backup stuff is the stuff I like very much. Got a damaged A-10C, we probably won't make it back, but look there's that abandoned airfield there, might make a difference, if not rescuing the whole airplane anyway versus landing on pure raw dirt, it should increase chances of pilot survivability, more systems and cargo surviving, leftover fuel surviving, electronic cargo such as image or film perhaps etc. And to put these emergency gameplay use cases into actual use, the new DCS ground RTS systems part of the big so called Dynamic Campaign, has to support systems with such features in mind, so you could have several actions on the emergency landed aircraft in a dirt or otherwise runway, should be able to extract ammunition and use them elsewhere, extract fuel and use it elsewhere, extract undamaged cargo and finally even extract parts of the surviving aircraft fuselage or systems. You have a broken Jammer system on A-10C ... use the one from that stuck A-10C on that abandoned airfield, DCS Dynamic Campaign system AI commands an utility/repair truck to location (with escort) and you already have a logistics mission right there which can be a little side-story to the overall campaign, then get the spare Jammer and bring it back ... ofcourse you as a Pilot probably wouldn't participate in that if you're waiting for replacement, or maybe you as a player would be, so whether Dynamic Campaign will allow for swapping which pilots you control so you as a player could be at multiple roles in one session (Kinda like GTA5 character select, interesting?) Also DCS Multiplayer would have to extend support for game modes where fuel, ammo, spare parts are limited and ejections and pilot deaths and respawns cactually do count in the final score or some kind of a gameplay affecting factor. Partially it's already doable with scripts and warehouse rules AFAIK, perhaps not simple enoguh due to manual work by mission designer. Furthermore on the map and aircraft physics level, these abandoned airfields should be officially supported physically, not just esthetical graphics on the terrain. The terrain underneath and the tires contacting it should be supported so that appropriate terrain behavior would be observed. It's a bit hard to do it accurately for aircraft which were never meant to be used on offroad runways so real documentation of the performance is most likely not existent or rare. Aircraft not designed for offroad runways should at least be able to land in DCS and that would count toward the stuff I was mentioning. Perhaps only some of them being able to take off again if they're barebone and light enough. in a limited ammo type of scenario it would matter, or perhaps important intel or cargo onboard, and perhaps only take-off if they're empty. So the actual use of these things beyond esthetics, would give options for player comeback and open up strategies for a greater overall DCS experience. However depends how deep the Dynamic Campaign base-building RTS component is planned to go and whether ED needs documented cases in real-life to justify simulating these rare emergency uses, like salvaging engine parts, extracting fuel, which I think don't really have a problem with reality, it's something a military would do if presented with the challenge, but there hasn't been a large scale war in real-life of that kind where these cases would manifest and get documented. It would be a feeling of pity if DCS wouldn't be able to simulate these very probable possibilities just becuase they never happened to occur in real life military history. Might be somewhat more work tho, crash-model or damage-model would need more variations, but might not be that hard if you just hide the parts that get salvaged(extracted). Pretty animations would need more work tho, the military utility/repair vehicles with several engneers around the aircraft extracting the engine is very complicated animation if you want to do it in great detail, but for DCS, really don't need the esthetics, any simple approach should be fine at first. If lacking documentation I think a group of SMEs that specialize in mechanics, rescue, repair from general fields too as well as the military engineers, and the SMEs that were ex or even active mehanics that repair the very aircraft we're talking about, I think that's a topic they would love to brainstorm, they could advise ED on the feasibility and likelyhood of something working or not or how would it work, so that we can enjoy these things in DCS which do not happen often in real life.

It's all about VRAM first and foremost, VRAM amounts are lagging behind due to the DRAM industry production bottlenecks, otherwise we'd already have 32GBs on these cards as per standard, and that would be enough to basically put one of the DCS maps fully into VRAM, but heavily depends on maps, with 32GB perhaps you could do that (I'm not on a system with DCS installed right now, so I can't have a quick check) RAM usage for gaming is in many cases as cache for VRAM data, graphics and texture data that the system needs in VRAM, but they either can't fit there, or aren't immediately necessary. So a high or low RAM usage isn't of a concern, there's no need to unnecessairly cache more unneeded graphics data into RAM, while VRAM is already being 100% utilized. The OP's GPU has 8GB VRAM and this isn't that much anymore, I have 8GB too and DCS's maps and everything would like to have much more if it could. Ofcourse VRAM alone doesn't mean that's the only blame for the OPs stuttering, we all know DCS is of a dire need to take advantage of modern software approaches in terms of multi-threading, resource management and graphics, which would enable a smoother experience even with not so optimal hardware resources. Most of the stuttering is actually more to do with CPU stuff than memory in my opinion. But yes, generally, we all know that software really should not stutter under a bit of resource constrain, if it's built to scale, if it has the ability to dynamically adjust it's output, but in a simulator you can't just not display an airplane or piece of land, it would look totally unrealistic, not to mention multiplayer unfairness if low-end users would see a less-detailed world and get some kind of an advantage, like seeing through forrest area or for, various environmental effects, etc. It might be interesting to see the comparison if for example you'd have game (DCS) debug and the OS too and disable RAM caching and just let the system deal with limited VRAM. However it be much worse on HDD and slow SSD storages than it would be today with fast NVMe SSDs, so either way it's not so bad like in the old days, but still ofcourse much less playable, any kind of stuttering can ruin the experience 10 fold. Either way RAM exchange has to happen on PCs because when you read new texture data from Storage, it has to go to RAM first, decompressed/converted by CPU before it can go to VRAM, but that's what DirectStorage is for, the data still has to go through RAM but the transport stack is apparently new and highly optimized for that VRAM upload to be much faster and the cost of GPU decompression is apparently much lesser as GPUs chrunch through that like nothing.

Khronos Strengthens Vulkan Ecosystem with Release of Vulkan 1.3, Public Roadmap and Profiles https://www.khronos.org/news/press/vulkan-reduces-fragmentation-and-provides-roadmap-visibility-for-developers I wouldn't be upset if 1.3 is the new target for DCS and we suffer a delay for that Let it be a blast when it finally comes. Actually 1.3 is more about officialy confirming many of the existing optional extensions (features) as part of the core and required, so DCS could have already been using some of these extensions already. Dynamic rendering is highlighted, but how useful to DCS at this point it is, is out of my experience to speculate and guess. https://www.khronos.org/blog/streamlining-render-passes On the other hand, some of the extensions are mainly about making it easier for development, not necessairly improving performance or adding new features, but it would mean with less hassle a speedier development can mean we would get the final result faster. https://www.khronos.org/blog/vulkan-1.3-and-roadmap-2022 https://www.phoronix.com/scan.php?page=article&item=vulkan-13-2022&num=1

Yes, youtube videos often seem to look better, tho I realized as well the creators probably enhcance things with Reshade which I think should be noted, but the video compression that youtube does also has it's side-effects that make it seem look better even tho it's technially not, they impose chroma-subsampling from 4:4:4 to 4:2:2 which loses color and pixels and should look worse than full RGB you get on the monitor. Other things the compression codec makes may indeed smoot things out in terms of aliasing so yeah, it's not 1:1 to what you see on the monitor.

Yes, I made a new year (2022) commitment to not post any half-assed posts anymore and if it takes me a month to do a proper post then so be it.