Worrazen

I'm not too sure if it's that big of a rewrite, it might really just be the CPU multi-threading, render-graph and Vulkan API, ... either way I think when it's all released we would be talking about DCS 3.0 at that point it seems. These are already big tasks so with stuff like this there's dillema of biting too much at once so I'm not expecting that all the tiniest corners would also get a redesign/rewrite, but it would be a bonus.

Agreed, not only is texture/world streaming a massive technological logistics challenge only silicon-valley cloud giants can afford, it's also not something hopefully the majority of DCS users really want or need for many reasons. It's already distracting if textures don't stream locally from Storage or even RAM to VRAM fast enough (or other CPU processing/programming bottlenecks), let alone from a variable and/or unreliable network connection. Technically anytihng's possible and DCS could lease cloud-server providers but it would cost a fortune. It's a costly convenience feature without that much of a core gameplay value. It's not that of a problem to have the Whole World with only the existing maps. While the core technology would need to be completely done and working, actual curvature and all the rest, then you don't need much of any world data, all it needs is low poly terrain and temporary textures in between the existing maps and it's enough for a first beta test, water is free because it's generated so it takes no time to develop, except shallows and coasts (and extras later), whole world is basically a giant water ball by default and then the terrain surface is inserted ontop.

I think your wishes should be justified, apparently there's a complete engine rewrite going on and while it would be unreasonable to expect we get it's potential fully realized initially, there are a couple of things I would try best to take care of for good before release: Fixed Alt-Tab Behavior, DCS is always in the background poking over windows and it's a struggle keeping it away, behavior slightly improved but still not perfect. Discharge GPU usage when Paused. Majority of GPU rendering should be suspended while the GUI keeps working ofcourse. Currently when you pause the game only game-time is suspended but not rendering, keeps ramming the GPU at 100% usage and makes the fans go crazy. That's how it is on 2 totally different PCs on my end. Probably fixing +10x other smaller quirks and inoptimalities in behavior that either weren't important enought to warrant special attention or didn't had good alternatives until now. When going over the whole game like this it's worthwhile to also touch upon the lesser areas of the engine, even the semantics and clarity that seems unimportant (but it can be a big deal for user experience) and alleviate those or completely bypass them around sort of for free as a consequence of a larger task.

Well the issue I'm having is with the official english cockpit, the Training Missions and the manual make less sense as they referr to systems with french names and abbreviations, there is no VIE in the english cockpit but rather STBY. And the tooltips of knobs do not line up either, so PCN is "INS Parameter Selector". This is the main thing that the new manual should address, having both versions equally addressed (ofcourse without doubling all the text). The other thing is consistency in english cockpit translation, EFFACE is kept as EFF, even tho shouldn't it be DEL for DELETE if we actually translate that?

Yeah, seems like there's more steps to do to edit, not like the cacuasus cold start training missions says.

Played Dune 2000 a lot back then, but too long for me to remember, I was quite young at the time so don't really remember the story in the game nor the books I see what you guys are talking about https://cnc.fandom.com/wiki/Ornithopter_(Dune_II) Oh, it's a general term ... heh.

Also, let's pay attention, the "MultiCore" list sounds to be more like a reference to the overall progress of the rewrite to the newer engine with render dependency graph technology, so it's not directly about threading at all. Parts or whole of some of those points may not be parallelizable so they'll run serially anyway, even if they would appear in separate threads, those would need to wait for their turn.

From listening and hanging out in various dev circles, there will always be a master thread that hold everything together, it just won't necessairly have the highest CPU usage all the time or at any time, and if it does have it, in case of calculations that simply can never be fully parallelized, it wouldn't be as high than the other threads compared to without multi-core enhancements. However there is some special programming in Doom Eternal where it keeps workload balanced across threads in a dynamic way is what I'm guessing is happening, litterally shifting work to another thread and the most active ones end up taking very similar amount of cycles, almost like a neck to neck horse race, but that game is not really comparable to DCS in many other aspects. I would say at least 6 months more to go, some of those items still on the list are big ones. Naoooo! It doesn't work like that, it's not a literal list of a number of threads, just a list of the component that are redesigned to be part of the multi-core enhancements upgrade, whatever that might be is up to the implementation only the developers best know. A proper dynamic system spawns as many threads as your system can optimally handle and group workload into them evenly. Technically each AI unit could be it's own thread, but that won't make sense on most computers, not only because each AI unit won't nearly take up enough processing power to max out a single CPU core of most modern processors, but because if you have 100 threads, your OS Thread Scheduler would just put those 90 into only a few CPU cores if you have a 6 or 8-core CPU, even tho it would feel like that there's so many threads doing the work depending on what kind of monitoring software you're looking at, in that case so many software threads can actually be detrimental, you're not going to lose much performance if you put 100 AIs onto one thread, as long as this thread doesn't completely max out a CPU core, however delays in AI processing aren't that big of a deal in long-.term, they shouldn't interrupt the core DCS engine and you wouldn't feel any slowdown at all, the AI would just take 0,xxx seconds longer to respond to some command or whatever, there's only a few areas where this would count, like missile avoidance, but that should run in a separate AI thread with very high priority, so there's many types of AI's, or components to an AI that can work independently, and thus can be parallelized to separate threads, and they should also be separated by priority indeed, the top-level coalition AI that controls strategic moves for the Dynamic Campaign would have the lowest CPU priority because delays even up to 10 seconds would not really be a big of a deal and wouldn't sway the outcome of the battles. It could be something like this: DCS Main Thread DCS Graphic Thread 1 DCS Graphics Thread 2 DCS Sound Thread 1 DCS GUI Thread 1 DCS Asset Loading Thread 1 DCS Asset Loading Thread 2 DCS Asset Loading Thread 3 DCS Asset Loading Thread 4 DCS Asset Loading Thread 5 DCS Asset Loading Thread 6 DCS Asset Loading Thread 7 DCS Asset Loading Thread 8 DCS ... etc DCS Dynamic-Campaign AI Thread 1: Coalition 1 Master Command AI Coalition 1 Ground Commander AI Coalition 1 Naval Commander AI Coalition 1 Airborne Commander AI Coalition 1 Base Operations and Logistics AI DCS Dynamic-Campaign AI Thread 2: Coalition 2 Master Command AI Coalition 2 Ground Commander AI Coalition 2 Naval Commander AI Coalition 2 Airborne Commander AI Coalition 2 Base Operations and Logistics AI DCS Unit AI Thread 1: Coalition 1 Flight 1 Commander AI (DCS Unit Group AI - Unit #1) Coalition 1 Flight 2 Commander AI Coalition 1 Flight ... Commander AI Coalition 1 Flight 20 Commander AI DCS Unit AI Thread 2: Coalition 1 Unit Group 1 Unit #2 AI Coalition 1 Unit Group 1 Unit #3 AI Coalition 1 Unit Group 1 Unit #.. AI Coalition 1 Unit Group 1 Unit #99 AI etc DCS Thread Misc ... etc However, the implementation of the AI might be completely different, as mentioned it has something to do with neural-processing, it might not resemble a structure that we see in practice at all and it may be a lot more integrated in it's thinking but also a lot more parallelizable under the hood because AI stuff can run on GPUs which are the kinds of parallel processing, so I might be totally off, maybe DCS will surpass this by far, but it could be like this 10-15 years ago if one wanted to do it, you culd do it like this and it would be better than , while NOT comparing it to how it is in DCS right now, because AI thinking really is not a bottleneck and I've never done AI testing. We also need to be careful what the heck do we mean with AI, because what I mean with AI generally is the pure AI unit/airplane/tank deciding what to do and to respond, pathing, etc, I usually don't count weapon/radar guidance/detection as an AI, even tho it probably does classify under the larger AI umbrella, there's a lot of physics involved and sometimes it's not that obvious which is AI, to a programmer it may go by the type of calculation rather than what we humans percieve it as "thinking" or not, but for sake of practical communication I think that a bomb falling through air even if it's laser guided, most of it isn't the AI doing it, the weapon AI is just correcting, most of that are still physics claculations, no? Then again I might be wrong, underestimating the cost of real-time corrections. This is a bit of a tangent that I wasn't really that deep into lately so I think you should not conclude absolutely anything with what I said. WHOA ... wait a minute, the benefit of this kind of AI command struture, as a practical implementation of the segments, not about AI multi-threading, would be if these battlefield commanders actually are physical units somewhere on the map and losing them you actually lose that specific AI ability and the thinking that specific AI field was responsible for, and the AI units relying on that would no longer receive these instruction (until it's replaced, if allowed by game rules). Huge gameplay depth opportunity. So if you lose Naval Commander on the map, you would lose Coalition Naval Commander AI functionality, that's kinda interesting if DCS goes to that length to simulate what a headless army would do, I think that's so interesting for gameplay, the lower levels would finish all the pending tasks from above but keep their own thinking and keep doing what they do by default without, stuff like self-defense and area patroling (if that's what they were taked to do in perpetuity) isn't something they should need the higher levels to order about every time an enemy unit is sighted, it's a bit of a process to determine what these default behaviors should be (tho in RL even perhaps self-defense use of weapons might need to be authorized so it's not so simple), definitely the lowest level unit keeps their AI thinking going, feeding information back to higher levels, their buddies in the squadron might hear his warnings of an enemy in the bushes but the nonexistend higher level wouldn't be able to forward that info to other commanders/squadrons/units, with a loss of a big commander, that force may kinda lose the big picture and probably lose effectiveness, you would have basically lack of strategic orders to move there or here but it shouldn't all crumble down completely, over a long period it would have quite a big impact ... it's actually a big topic so I don't want to get too deep into it, but boy it was worth brainstorming with the AI stuff so I got to this. Then there's even a more complicated aspect of the Top level bypassing the incapacitated middle command and giving order down to the lowest level units, that should work, so if Master Commander AI makes those big strategic moves to move forces to a completely new area, that should get through and units would listen .... but here's a catch, how would they execute that move may be crippled, they might not use the best path to get there possibly taking the riskiest approach because there's no middle command thinking about how do it in the best and safest but also effectivest ... this is some complex AI stuff there, you'd have to account for all possible combinations of KIA commanders, etc, I'd be surprised if DCS would think about this at all, but if Dynamic Campaign is such a big deal and the returns are worth it I'd say go ahead! Indeed it most likely would, but the number of threads it might spawn may be dependent on your system so it may not be the same with all the players, people shouldn't be worried if they don't see 100 threads for so many components that can technically be parallelized, the system should probably spawn threads in mid-game if it needs to do so under heavy load. Purely more threads on a CPU that can't handle all of them simulateneously isn't benefitial at all, if you have 100 boxes, you'll still have to put them on 8 trucks with an 8-core CPU, so it's easier to just use 32 or 16 bigger boxes instead. But I don't really know what kind of load balancing DCS will have, if we have huge battles with thousands of units, there is no need to have a 1000 threads for each of the unit's AI's and other components, so much of that would be grouped together, because so many threads would actually stress the OS and internal CPU scheduling and introduce a performance penalty, right the opposite effect, AFAIK. Keeping those cores that you have well fed is the key thing rather than the pure amount of them. I'm generally speaking btw, not as if the quoted doesn't know this already.

In my ears it sounds the other way around, accomplished for development branch, I think the changes would make quite a noticable difference without any patch notes.

I accidentially came across "IndicationTextures" and "IndicationResources" in many Cockpit folders of aircraft module files stored in "Mods" folder, they're exactly that, the GUI indications for HUD, RWR, MFD/MFCD/DDI ... let alone the Mission Editor and F10 map with hundreds if not thousands of icons and does make a lot of sense to me, because you can have all of those indications in the cockpit duplicated in case of a lot of action, and a lot of units on the map need a lot of indications on the HSI for example. I remember long ago I made a thread about how Mission Editor grid is being rendered and I guess the multi-threading improvements and the new Vulkan API will alleviate the performance hit of some of these indications in ME. Now, Mission Editor it self is not on the list but we can probably safely assume it'll run a lot lighter as well, no?

Understood, but the raw development notes usually originate from Russian I would assume, at least the patch notes almost always definitely do because there's always a lot of small translation errors there, usually word ordering, not that that's some big deal, usually it's totally fine and I'm used to it. In this case I have no idea what could Indication be, maybe I'll figure it out of I go an play a mission or two.

@NineLine I think I have a slight suspicion there could be a translation error in MultiCore for "Indication", the original word, perhaps it was "ukazaniye" might have more meanings depending on context and it could also translate into "pointing", "direction" or "designation" which is similar to "inputs" or "controls" in our case with DCS, even tho if I put the "controls" or "inputs" into the translator for a reverse translation, it threws out different words in russian that don't connect with the "indication" so I'm not sure. Furthermore, I'm not russian but kinda close and many words are quite familiar-sounding to me (but many have different meaninings, sometimes completely different, even if they write exactly the same) and the russian term "ukazaniye" is very similar to what would mean "order" or "instruction" or "command" in my own language. I don't seem to understand what is meant by "Indication", perhaps it's just a brainfreeze and it's something that should be obvious on my end but I'm not getting it, Like the cockpit warnings, it can't be that, because Inputs&Controls makes more sense in this case than some visual "indications" on some specific unit in-game, right?

For some reason I read (or heard) that as "BESIDE", I guess my mistake. No I couldn't contact ATC on Batumi, because the comm link stayed open with it (double >>) stuck at Landing in progress, only displaying F12 Exit and F11 Previous Menu, but it takes you out to select ATC, and no option to abort landing or restart.

Yes, well, I parked beside him to the right, and the refuled parked to the right of me, I think I parked to the left in the first try, I failed in the first attempt for an unrelated reason. Actually I completed the mission OK just a moment ago, so this ATC thing doesn't count in terms of scripting.

Seems like on the Boats & Planes mission where you have to refuel at batumi, the ATC does not recognize you have parked and will not give option to contact for takeoff again, I haven't tried shutting off the airplane (to spare me a realignment) but I did park and drive around and it didn't work. Hopefully it doesn't stop from completing the mission.

Hi There could be a small coordinate mode indicator to let you know what coordinate system/indication type is currently selected on the F10 map and ME, I think there is enough horizontal space that it wouldn't hurt, for now at least.

https://www.bitchute.com/video/wU0Qe3XAXGlE/

Hi, I think I mentioned this in the past somewhere long ago, but when copy pasting aircraft, the waypoints that are set to Landing or LandReFuAr should be locked and not offset by the relative new copy+paste location, they're also converted to normal turning points at the same time. Or perhaps a new system of pathing waypoints and copy+pasting is being devised that would offer such and other flexibility. In the meantime just clamping those to stay Landing and point to the same airport would do the trick. Thanks

The obvious worry is that there is not a big enough market for a full fidelity flyable C-130 or any transporter, and a full price module for just one airplane. The last time I discussed this it ended on let's get the AI external model and paradrop functionalities first, which may be a module too perhaps if necessary to speed it up if necessary. If there would be a module, for just the above mentioned, then I think it makes sense and may do well if it's something like an "AI Air Transport Pack" or "Wide Wing AI Pack" which would include great external models of several transporters, tankers, awacs from more than one country, perhaps other variations of already existing ones in the core, include a number of AI functionalities not currently present and good editor support to do complicated drop patterns and pathing behavior (but yes perhaps core paratrooping tech would be free for all, and 3rd-parties) and someone who doesn't own it would perhaps be able to play with it but not host such missions nor open them in editor, or use the assets in a new custom mission. From the interview's weak translation I forgot about the AI-only versus Full-Fidelity there, so I thought it meant that the full-fidelity one is planned for a 3rd-party to pick up and not started anything yet, there was no mention of AI so I guess they were indeed talking about actual possibility of a full fidelity transprter, that's cool to hear if true, what I fear is that if we do get the AI-only stuff before, and we kinda should, would it make the full fidelity fliable one less appealing if everyone would get most of the use out of it with the AI paradrops anyway? I still pick the first option, worry about making the full-fidelity worth it later, again it could be a module pack with more than just one aircraft to make it worthwhile to buyers if that's an issue.

That would usually mean reliant on some external online service, not the most optimal choice for MP. Unless you manage to persuade for a local offline implementation without 50 pages of privacy policies.

Hello While playing, in this case it was a multiplayer caucasus mission, GUI elements for the Rearming Window disappeared, things like pylon weapon icons, slider buttons, and other indicators, later I realized the whole menus, options and controls were also missing some elements, lastly, the main menu as well, all the module icons were missing too, as well as other items. However it's visually only, the underlying functionality still works, things can still be clicked on, but it is harder to use because you do not see what you are doing, you can't see the silhouette of the selected weapon in the rearming window, but the numerals for pylon carriers still show up, so a number 2 or 3 is still visible, but doesn't help much. Yes I do have an AMD GPU and this never happened to me before, seems like it's after the lastest beta patch, I am however still running the older GPU drivers I was running for a couple of months now, through several patches. I will update the drivers shortly, but I will first wait to see if perhaps the newer drivers are problematic and perhaps wait a bit longer for an AMD fix, if this is really related to AMD GPUs. AMD Radeon RX480 Software Version - 2021.0413.1252.23166 Driver Version - 21.4.1 Provider - Advanced Micro Devices, Inc. 2D Driver Version - 8.1.1.1634 Direct3D® Version - 9.14.10.01494 OpenGL® Version - 29.20.11000.14830 AMD Audio Driver Version - 10.0.1.18 Vulkan™ Driver Version - 2.0.179 Vulkan™ API Version - 1.2.170 Windows Version - Windows 10 (64 bit)

Some of the underlying code may already be there and could be used/recycled, the DCS updater already supports detecting "local copies" (other installations) that it can use the common data from, so it doesn't necessairly need a compressed+difference patch packet and can already work with another end-user installation already. But doing it right and good probably will be a bit more than just bolting LAN on this, it's just one more argument I could find in favor for this idea and the feasibility hehe ... but I'm speculating honestly not have an idea what the code is like.

Oh hehe, my personal case isn't as a serious network shortage, I do have ~23 MB/s down, ... and I guess why would I even need to update both machines at once, not like I could play both at the same time, so I'm not the best example, but it would help for others in a similar situation if there's more actual people on a LAN that might also have a slower internet, and to avoid splitting that bandwidth to all the LAN clients. But some of my builds I did not update for a while so I got a 30 gig update, which isn't abnormal, patch sizes, but also new module/terrains are going to get bigger and bigger and this isn't that far fetched of an idea down the line. Realistically this would help in less popular situations, but when it does, it may relieve the official servers and save bandwidth there, which most likely isn't free I would think, and the returns start piling up the more LAN clients there are trying to get the latest patch down roughtly at the same time/day. What about the student dorms, university, apartment complexes, those most likely have a single cable to the building and one internet plug, there might be (exaggerating to prove my point) a 100 people on the same LAN there that would be all doing their own direct connection to the official patch servers, on the other hand perhaps not so popular scenario again, not the kind of demographic that is big for DCS but it's still a good argument in terms of how much savings this feature theoretically brings when you have a lot of LAN clients. For simulatneous LAN updating, the implementation idea that first pops in my mind is: DCS updater which starts first would become the primary one by default if there's no other DCS updater instance detected on LAN, basically DCS updater would do such a listen check for a few seconds every time it starts and then proceed according to the results, if it detects one it switches to client mode for LAN reception, if nothing is detected it's going to direct download but also into host mode and keeps broadcasting it's presence on LAN while subsequent other LAN clients would detect a primary already exists and let him download at full speed from the WAN, with an option/button to switch over to direct mode if the user so wishes, in case of issue. Simulatenous LAN updating has a benefit over the "offline" manual idea that I had in the first post, because the DCS Updater in Host mode could (and probably already does, and cleanup at finish) cache the downloaded patch data (which is a compressed and probably also difference-data which avoid replacing whole assets but don't hold me work if DCS actually does this, I don't know, but many games do) so any other LAN client in DCS Updater client mode would ofcourse get this cached data really fast and then receive the remainder at pretty much the same speed the Host is receiving it from WAN. Another feature/behavior of the Host mode DCS updater would be, when the Host finished it's download, but senses there's LAN clients still connected and did not finish, it should wait and keep transferring to them until they're finished ofcourse. This actually is more of an odd case, the clients would most likely finish nearly simultaneously with the host, except if a DCS Updater LAN Client joins in very late and even at the very high LAN speed it is not able to download all of the cached patch data in time to catch up, among other possible reasons, such as LAN congestion it self. Additionally there could even be checks to warn the user if LAN isn't working properly, if possible, for example if a firewall or something blocked the connection from going fully though, or the DCS updater Host could not properly broadcast packets and senses some issue, etc, but ofcourse such things aren't 100% checkable as an improperly configured LAN or simply LAN connections blocked by the organization as a policy of the operating system or network equipment (router) might look the same in practice as if there's no client to be found, which I'm afraid some larger LAN networks might be doing, especially wireless APs, to isolate different devices/rooms as a security and privacy measure. https://www.asus.com/support/FAQ/1044821/ Yeah so a possible note in the DCS Updater could be, even if there is no LAN issue detected, that if the user feels like there should be a host/client on the LAN but it's not being detected by the DCS updater, the user should check or negotiate with network administrator whether the "AP Isolation" option is disabled on the router, among other possible network configurations. However, reading the FAQ now, even with this enabled, actually it looks like AP Isolation isn't fully-encompasing as I thougth, as it works on a per-interface level, so in a big complex network there might be a lot of other possible LAN clients that this would work through. But still instead of everyone having their own connection, let's say a 100, let's say there's 10 Wireless APs with AP Isolation enabled, you'd still get significant savings, each AP would need it's own DCS Updater LAN Host so there would be 10 hosts in total and 90 clients, now that's still a lot better, a lot of GBs saved there on the official servers. PS: Yeah the "offline" manually triggered DCS Updater LAN Host option could still work better if you would simply keep the last update cached forever without cleanup, but that's getting really nitpicky even for my pickyness, however that might just be fine and perhaps useful without turning DCS into a server mirror or something, which isn't the intent, but just for the very last patch and nothing else, so every new patch would overwrite this cache, for the option that could go "Keep last patch data cached" or better. As usual I dig into an idea really good, it's been floating on my mind for months.