trevoC

Have definitely noticed this. I'd say about 60% of the engagements in this campaign were hard deck breaks. Also noticed a lot of other campaigns where for e.g. you are faced with 6 hostiles and 2 or 3 of them fly into the ground before you even engage them. (maybe one missile sent their way but 2 or 3 will hit the ground to avoid it). ED needs to have a look at this. The AI behavior should definitely avoid the ground before avoiding a missile. Both are bad, but one is a guaranteed rapid disassembly.

Same here.... on my third attempt I just started the aircraft as fast as possible and taxied out as soon as the first engine was capable. My first attempt had this superhero rip my landing gear off.

Great campaign, but on the mission to re-locate from the one base Vasiani ? to the other, on load there are three troops who are running around near the aircraft. On my first two attempts one of the soliders keeps walking into the aircraft. Apparently he is a superhero and ends up pushing the F-15 sideways trying to complete his path. Broke my landing gear on the first attempt and pushed me sideways in the bunker on the second. Third attempt I started as quick as possible and taxied out of the hanger before the second engine was started to get away from him allowing me to complete the mission. I'd just remove those troops from the mission. I think its mission 8

Thanks, just wasn't sure if I had already received this patch or not. (If I had I was reporting that they are still hitting the hard deck). Almost finished the campaign so it won't matter but I'll re-fly one or two of them to see how the behavior is different after the patch. Thanks for the response.

Just an FYI, I just flew another mission. I have no options to tell him to RTB or hold. There is no wingman or flight menu. Only ATC/Tanker/Other>Copy. On approach I am eagle eyeing him for his break left at which point I dive hard which is not the nicest thing to do on a 3 degree approach on the numbers giving me very little time to react and land. Not a big deal as landing the F-15 is pretty easy, but its not nice being constantly on edge about racking up another death on your profile. More importantly it breaks immersion in a pretty decently immersive campaign. Not that your campaign is to blame for all my profile deaths, but the AI in general is to blame for around 50% of the 45 deaths I've racked up over the years. I've accumulated 2 on this campaign so far, both on approach.

Yes please. Also, combat hot air balloons.

I'll have to check again, but I don't think he is "officially" my wingman in the comms menu. I usually do this on other campaigns but remember looking for this the first time he almost dinged me and couldn't see the wingman or flight menu. Will look again.

This happens every mission although up until now it has only been near misses. After completion I'm on an ILS approach to Nellis 21R and my wingman is right beside me. At some point he decides to break left (towards me) and usually up enough to miss me. Mission 6 (M-2000's) I'm on approach and in a split second I'm dead as he breaks left right into me. I can provide a track file if you like, but I'm guessing this is known as it happens every mission. So now, I have committed fratricide and have lost all my combat score. Would it not be easy enough to have him either break right or break off before the approach?

Is there a reason my post was removed? I had asked if the update this was included in was already released or not?

Full Fidelity Su-25 Would be close to the top on my list. Other Bomber Aircraft (F-111 / B1-B / TU-22/95/160) I feel that as DCS is a free to play (with Su-25T) that it doesn't really showcase the software well enough unless you purchase more modules. I think it would be nice for DCS to come with all three versions of the SU-25 (FC3 version, Su-25T and a full fidelity version). Players could then start wherever they are comfortable but see the capabilities of a full fidelity module. To be clear, I'd pay for a FF su-25, I just think it would complement the free product well. That aircraft got me hooked back in the day with the original FC. At very least, I think the Su-25T should get a cockpit/model upgrade to showcase the software. It should be one of the best aircraft IMO to attract people buying modules.

In general, newegg and Amazon and all other sites included, I try to stay away from the vendor or 3'rd party sellers. This probably keeps me away from most of the scams. I prefer Amazon for their return policy. Never had an issue. I've always considered newegg (US or Canada, have used both) as a decent company personally.

Never had a problem with newegg once and I've ordered dozens of gpus from them and other various system components over the years. They are my goto for items that are either not available by amazon or less expensive than amazon.

I didn't say they were. Again, this entire conversation has digressed from a point I never mentioned.

I never said anything about multi-core Processors. I stated I've been working on multithreading my entire career (almost). That idea was around long before my work in posix and mainframe computers. (it wasn't a new idea when I learnt about it in books). I'm guessing multithreading pre-dates my work on my first computer by longer than I've been using computers. A 286 16 (sounds like an IBM ps/2) was a pretty nice machine from where I started. In fact having a math co-processor was nice once upon a time in consumer pcs. Not sure that has anything to do with anything though. Sounds like we've both been around for a while. I remember being the envy on the block with an 8088 and a 4-color monitor. I believe that was my 3'rd computer and first that wasn't a hand me down. Even in personal PC's Dual Pentiums were available before the dual Cores arrived. I had plenty of dual chips on board back in the day. (before 2005) Off the top of my head I believe 2000's era was Dual Pentiums. (I remember dual 386's I believe but never used one, dual or quad etc... processors go way farther back though, just not on the same m/b, multi-bus connectors connected multiple computers together for penalization. I never saw these outside mainframes. In my era, the dual pentium 4's were the explosion of cheap office servers that were not considered dedicated server hardware within the industry. Every office in town no matter the size were buying these.) A program that can use multiple cores does not necessarily make any of the processes multithreaded. In fact its usually not the case as targeting different cores with different loops or processes (not running processes as you have alluded I meant just for the record.) is much easier than creating a multithreaded application that can scale across any available threads. DCS at present and as advertised in the announcement is the former as far as I can tell from the limited information. You could split an application up to use 40 threads if you like and still not have the scalability that multithreading offers. How many threads your CPU offers per core is irrelevant. I think the use of certain words and the context in which I am using them is being mixed up.

To be fair, the context I was responding to "infinitely" was within the obvious bounds of whatever processor you are using. This would obviously be the upper bound. I guessed infinitely was used to mean the entire processor and more cores if given.

Although I understand where you are coming from, I disagree. Great progress is being made towards this end. History suggests we will do incredible things and never need more than 640KB of RAM. The future of Moore's law is in scalability, not single core speeds. Industries will follow albeit slowly.

I agree with many of the items you have stated in your post skate, but unfortunately the definition of multi does not apply to multithreading which is actually one word. Although I don't develop games (should say by trade as I have and do develop games for fun), I have been building multithreaded applications almost as long as I've been coding in general (over 30 years). In this context, splitting logical pieces of codes (or their loops) into separate processes to run on separate processors is not multithreading. multithreading in the context of programming would be a single logical piece of code (the graphics loop as it was referred to for instance) being able to use multiple processors, allowing it to scale. What DCS is doing now and looks like this announcement is mentioning is multiprocessing. Separate logical process executing on separate processors. Very different than multithreading because obviously you cannot scale any of these independent processes past 1 processor. The worst offending process will always be your bottleneck. Multithreading does not have this problem. A multithreaded process or application does not have the same type of bottlenecks. It does introduce a crap ton of problems and other issues, but I digress. All of this is welcome, and noone is complaining from my end anyway, just discussing the difference and setting expectations. As I have mentioned earlier in this thread, sending the draw calls direct to GPU (bypassing the CPU) with DX12 or vulcan will probably see more gains than multithreading anyhow. That beings said, this was only an attempt to clear up the use of the word in this thread thus far. Reflected's campaign is the one I was thinking of. It will probably be the first campaign I will re-visit (I paused it after I think mission 5 because of the slideshow I was getting). So yes, this change will be welcome for this scenario.

I think you are misreading the temperature here. Multi-threading is important for many VR users as we are currently limited by the CPU. What is disappointing for us is not being able to buy more modern hardware and get any realistic performance boost in VR. Multi-threading (allowing these processes to scale with hardware) will fix that and allow us to get better hardware to fix this. Although the upgrade from a 2080ti to 3090 did see gains, the 3090 is not maxed out but rather the CPU at this point. The current graphics/logic split will not necessarily help the majority of the VR users who are CPU limited to gain much performance. It will be nice not dropping down to a slide show during the WWII campaigns when 50 bombers drop their loads, so that's nice and any improvement is welcome by all I believe, its just not multi-threading. Splitting a loop into two loops and putting it on two different cores may look like multi-threading to some, but it is not. Regardless of the performance gains by doing this first step (which don't get me wrong, is welcome. Not every time I express an opinion that is not "I love it' am I being negative towards ED or the community), regardless of these gains, we will immediately and quickly reach the same CPU limits until we are able to scale the largest bottleneck across multiple cores as needed and on demand, which is multi-threading. Although there is the odd more negative than neutral comment here, I don't think the vibe is booooo. Its just a discussion. You have to expect some disappointment from VR users who are currently limited by the software instead of their hardware.

I had a 1070ti, then 2080ti and now 3090. Each of these steps showed large improvements in VR. Yes, you don't need a 3090 to play at 1080p or 1440p for that matter. 4K maxed in MSFS or 2K VR in DCS/MSFS, the 3090 is a marked improvement over the 2080ti. Again, it depends on your setup. If you are gaming at 1440p, then probably not so much, but at 4K or 2K+VR you will absolutely see gains. Not sure how anything for flight sim is overkill if there are gains to be had. That being said, the context here is DCS so I'm not sure how the overkill for gaming applies here.

That just isn't true at all. My 24GB of ram are usually full (close to). Also, enterprise cards? I wish. Would save me 10's of thousands at work. The 3090 is pretty well saturated in MSFS. It just so happens that its not the bottleneck with DCS in VR. 3090 over 3080 in MSFS yields 20-25% gains. (enterprise perspective... a six year old p6000 will outperform a 3090 in certain business applications)

Also don't envy you here.. .lol so true. I like the news, i get it. Probably hard to come up with good newsletter material every single week also. I prefer to have the insights personally. I also recognize that development or testing is not an easy thing to anticipate completeness on. One could argue its never complete. The most difficult thing I ever do is deciding on a point at which it is complete enough to use. If your developers are anything like me, it could always use another feature or perform a bit better etc.. etc... feature creep and perfectionism prevents many a ship date. I digress. I personally enjoy any amount of insight into DCS and I think most would agree.

Thats how I read it. Not multi-threaded, just separate single threaded loops for graphics/logic. To be clear... I'll take it, but not what I was hoping for. In all fairness, multi-threading is extremally difficult with games. I'm a developer by trade (ERP manufacturing and server systems, not games) and multi-threading for that is infinitely less difficult, but still difficult so I'm not proposing this is easy to do, but it is what I thought they were working on. Inevitably, splitting loops that are not related to separate threads will always help (and is usually the path of least resistance) but will always leave you with a single thread that is always dominating a single core and your bottleneck. Unfortunately with many processes its very difficult to split them up as they have dependencies and require specific timings that would need a very complex scheduler which sometimes is more overhead than its worth. Not all tasks can be completed in parallel unfortunately. I'm guessing this is the case when rendering frames. Business applications are a little different as the main factor is how long it takes to complete a task rather than a very specific 30 tasks a second that need to be in order to make sense. I don't envy the developers here but I'm guessing this is a step (band-aid) towards vulkan which I'm guessing will offer them tools towards this. A pressure relief valve if you will. I'd bet that reducing the draw calls that the CPU has to handle (direct to GPU) would do more for CPU limited cases than multi-threading the draw calls in most cases (flight sims being one of the highest cases I'd guess). Either way, looking forward to any DCS releases and updates towards this end. This is one of the first times a GPU (4090) is being released that I haven't tried to acquire one immediately as I doubt I'll see any difference in overall frame rates. Will wait for the 79XXx3d series cpu's first to see how they play compared to 13'th gen in single core performance to see if I can bottleneck the 3090 first.

I think after re-reading your comment we are sort of talking about 2 ends to the same problem. You are talking more about reducing the fps drop during heavy missions (which I agree would be improved by the split programming loops) while I'm talking more about the total increase in fps for VR users to take advantage of their GPU's In my scenario although removal of any amount of processing from the graphics thread will help, in a free flight scenario for instance as a benchmark, I don't think it will help as much as you might think. Regardless of how much it might help, I'm more worried about hitting that upper bound again very quickly as 4k+ VR easily doubles current requirements from a G2 headset scenario which puts us in the same boat very quickly. The answer really is bypassing the draw calls IMO. I'm guessing from what I've heard that this is not the vulkan update, but rather a core re-write which might act as a band-aid for the time being until vulkan.

I'm absolutely limited (as would most) by the graphics thread. Yes, you are correct, in a heavy mission, the logical calculations saturates the main thread, but in a free flight scenario the upper fps limit is bound by the draw calls to the gpu that the cpu can handle. Graphics are usually limited by the CPU making the appropriate calls to the gpu. This is why new engines allow these calls to circumnavigate the cpu all together and make the calls directly. This isn't a problem for high end 4k 2d, but VR users are most likely (like myself) bound by the number of CPU calls the single core is able to make which is only exacerbated by a heavy mission load. my 3090 rarely exceeds 70% utilization in VR.

I got the tone from this that this is less a multi-threaded update and more a split threaded upgrade. (splitting the logic and graphics threads from a main thread to split threads for each, neither of which could task multiple threads with higher workloads). Not that I'm not truly looking forward to this upgrade as I've been CPU limited for a while, but I wonder with better 4k+ VR headsets on the horizon if we won't be faced with the same upper limit very quickly if we only have a single Graphical thread. Even with the logical thread, this seems like a clear candidate for true multi-threading. Please correct me if I'm wrong.