zerO_crash

Supporting it a 100%! Also, fantastic work with the information gathering @Jaku Ugra -> $$$

It's been already mentioned many times, but I'll remind everyone of the fact that MiG-21Bis was built using many custom solutions due to there being no official ways to program in or code the workings of many of the systems. Hence, a 2.0 is effectively a new module, built from scratch. This shouldn't be looked at as a obligation from the developer either, as they pretty much delivered as well as they could within an already delayed timeframe. As such, if we are to be truly delivered a new module with new technologies and implementations (and hopefully more variants of the aircraft), I suggest that people people here grow up and realize that 60$ is borderline an insult to the producers. Wages and prices go up (it's called inflation), yet you all suggest that the cost of a module should remain constant since about 15 years now! How about reversing the logic and instead realizing, that we should be happy for any Redfor module we get (given that the most popular ones are bling-bling western ones), and in addition, that a dev. has to invest around 2 million USD to create a module alone... I for one, will state that given the risk-factor and upfront payment, I don't see any problem at all with the devs claiming a 80+ USD reward for their product. Whatever the MiG-21 lacks in digital suites, it more than makes up for in analogue systems, which often are more complex to design for proper feel and quirk. @Magnitude3 LLC I say don't bother with the "5 dollar too expensive..."- part of the community, instead, show what you are capable of! I'll happily buy multiple licenses just to reward a quality product, and support ambition and innovation!

As Hammer1-1 states, diluting the oil is a possibility. One can try it (the nice thing about a simulator), however in practice, I'd be careful with altering any part of such a critical procedure. Warm-up processes, although written as simple as possible for the pilot to follow, will often bear less obvious effects to the untrained eye. Heating up the fluid is one thing, heating up the specific parts of the engine, is another. The closer you get to the destined heat level of a fluid, the easier it will be for the heating source to compensate for the delta loss of heat exchange inside the engine. What I'm essentially saying, is that there are parts inside the engine that need to be heated up as well (often rubber parts/other lubricants/pieces of metals that are designed to accept a certain level of flex, etc...), besides the fluid, and in this case, the temp. sensor might not pick the loss in temperature over the circuit, because the loss in temperature is small enough and source of heat able to heat it quickly enough. If you don't give them proper time to heat up to their designed temperature, you might very well end up causing more wear and tear, and not even be aware of it. One thing I can give you an example of is that oil, besides lubricating, is used for cleaning the system as well (from metal pieces and dust pollution). If you don't allow the oil to cycle through enough, it simply won't clean the system properly, to the point where metal bits and pieces could cause a catastrophic failiure of the engine. As a tip - I'm not an enemy of trying new things, quite contrary. However, with props., I'd much rather perfect taxiing and multitasking (setting flaps while taxiing, and otherwise doing all the checks prior to take-off), before attempting to alter such critical procedures. Especially since you'd really need to read a maintenance or technical manual, in order to be sure that you aren't causing the engine harm.

I'll add that, depending on the version of the Me262 chosen, it might either feature a Junkers Jumo 004, or a version of it (smaller modifications). Regardless of the engine made, in the worst case, make the 004B, and now you have the engines ready for a Ho229. There are plenty of allied aircraft using the same/similar (variants) of engines as well. The deal would be sweet for both sides (customer/ED).

Hi, I'd like to request multiple types of shells for the Mk-108 Motorkanone on the Bf-109 K4 (AP, HE (Mine shells), HEI). In addition, not sure why it wasn't added, but there should be a mix including tracers (in different proprtions). It can be observed from WWII videos of Mk-108 use (Bf-109, Me-262, +++) that these cannons would often be equipped with tracers for air combat, and not only. Tracers in particular, are a major lacking feature. I understand that making ballistics for new shells will/might take time, but please do consider an ASAP implementation for the tracers themselves. Thanks in advance!

Frankly, maybe ED can consider growing their WWII department somewhat and give the era more well deserved focus as well. It's important to keep in mind that while DCS has amazing depth overall, when it comes to physics, helicopters and prop. aircraft are among the most visible instances that simply make this simulation play in a league of its own. I have no doubt whatsoever, that our promised Me-262 would sell like hotcakes, even to those who are inherently not interested in WWII (imagine getting to try the closest-to-life simulation of the worlds first mass produced jet fighter?!). That said, other aircraft (e.g. something with torpedoes, or other unique armament/aircraft) would truly shine as well. This becomes even more apparent when one considers how much customers ED can snap from games out there. I'm happy for what we have, and a steady and stable expansion is better than rushed and not thought through (thinking of the business practice itself here), but the overall benefit from a grown WWII division would be immense (based on observation).

Fantastic news! It's great to see things happening behind the stage Good find @MiG21bisFishbedL !

Splendid! Couldn't be better!

First and foremost, thanks for the amazing and pro-bono work you do, Currenthill! To talk about the attention to detail, or overall fidelity of the units doesn't even begin to cover it. This is by all means, art! The pedant in me can claim that you have much to be proud of, don't take that lightly either! I'm not sure what plans you have in store for the future, obviously the units you present on your www. are a fine work, and implementing more of them into DCS natively, would be a dream. However, I do also look at this from the perspective of a mission designer (when not in the air). It would of course be awesome to have the Ka-52 AI implemented, as well as simply more of the units that you bring. Even more civilian, with different color palettes on each unit. It allows for creating more vivid and realistic scenarios. A place where I see an immediate deficit in unit choice, asumming it could be of interest to you, is the department of soldiers/civilians. We currently have very few models of soldiers, and even fewer if you consider the new high-quality ones, that are properly animated. I am wondering if you would be interested in widening this aspect of the simulation. Have more soldiers, from different countries, with variations of weapons/apparel/camo patterns/colors/ranks? As an example, even adding a basic model of a recognizable officer (prestige uniform), would already open the doors to creating missions where a pilot might need to verify/engage or verify/protect a high-ranking persona. With the addition of more transport modules (Huey, Mi-8, Mi-24, CH-47F, C-130J (soon), +++), this would not only bring more authentic feel to the transport mission, but also allow to create more varied combat environments. I hope this could be of interest to you, appreciate your work again, and do keep the models coming. Uploading some WIP missions that show just how a creative mission designer can untilize such units! You give us the tools, and this is the effect (not complete)

Luckily, Russian aircraft more than make up for the lack of Yugo aircraft. That is even more true, when considering the latest AI units/structures added by CN and ED. We have enough variety to simulate this area. What speaks even more in our favour, is the sheer fact that any testimony from the wars in Balkans, will confirm that due to extremely similar uniforms, language and culture among the local populous, the theatre was a nightmare in terms of ROE and IFF. It would be refreshing to make IFFing and SA a major consideration again. You know, make you think twice before pulling the trigger. The mix of the terrain type, and close proximity to both Italy (NATO) as well as Adriatic and Ionian seas... Yes please! It would be important though, to have the map be from around 80s-90s for optical coherency and authenticity. Much of this aspect lies in real estate models, cars, and otherwise all the detailed objects. That's what e.g. makes the atmosphere to splendid on the other maps, and that's what would do here.

Uploaded both the .trk and .miz. It's a simple and short setup placed on Caucasus. The Grad (first of three units to test-fire at the C-RAMs) starts firing just after 02:00 minutes into the mission. I also purposefully didn't put the C-RAMs into one single group (rather all four individual) in order to give them different setups (one is set to not fire below 100m AGL, etc...). Some observations made by me based on this quick setup, and more complex missions: - It can be observed that the unit doesn't even engage the 120mm mortars (third and last group to fire at the C-RAMs). This is contradictory to public information on the unit, where it got created for the reason to " ... counter indirect fire from mortars on US bases...". The S-8 rockets are detected and intercepted just fine. *1 - The range at which the C-RAMs engage might seem a little short, but I have no conclusive data on this. This is purely based on IRL videos showing the system in action. - It can further be observed, that all of the C-RAMs fire, and well into the ground, even the one specified not to engage below 100m AGL. If these units were placed in a base (natural habitat), there would be blue-blue collateral. - It can also be observed that as the C-RAMs get overwhelmed by the GRAD, their turrets at some point keep pointing at the ground and aim for targets that shouldn't be there. There is a target priority issue here. - In more complex missions, even maintaining above 45 fps, I notice that the C-RAMs might not perform well at all (won't spot incoming fire from S-8 units, nor engage). This might point to a greater AI issue, as I've noticed that with 1500 units +, there are certain "artifacts" in the AIs behavior, not only related to C-RAMs, but e.g. artillery units. This warrants more investigation, as I've even had them C-RAMs in a group of units, and they all end up targeting and firing on the same incoming threats. Overall, there is no target distribution per se, the logic is very poor/non-existent, priority system non-existent (simply target the next in incoming queue), no smart algorithms, +++. This results in the unit being rather flashy, more so than useful. *1 C-RAM Centurion Phalanx LPWS C-RAM CAUCASUS TEST.trk LPWS C-RAM TEST.miz

As a red4life pilot, I have admit that those are some fantastic news! Eurofighter was already a much welcomed surprise, but Rafale in addition, makes me a double agent now! Amazing! Keep at it ED & 3rd parties!

It still doesn't work. Firing at the ground, tracking munitions below the ground, generally, not really usable in the capacity it was meant to. I have a simple mission showing the problem if it's still needed.

Bumping this, as this is still a problem. Practically useless unit, until the above-mentioned bugs get solved.

True as well

Since this thread has been revived a couple of times. Just to straight it out: The problem isn't with the Vikhrs or Iglas damage simulation, but with older (and certain) AI models lacking a proper damage model. Those few units that lack in-depth damage modelling, are simply damged based on a life-bar. The unit either works 100%, or is destroyed (0%). Hence, until you fully kill it (with often ridiculous amounts of hits), it won't really degrade in performance or experience failure of parts (e.g. engines). Everything will get updated at some point.

My regards to the team for implementing such awesome depth, even going beyond systems themselves. Forces pilots to stay weary during what they might have considered as monotone before (target ID/SA).

What Ironhand said. It would be amazing, no doubt, but the region is too politically challenged, and too recently. If peace isn't signed tomorrow, and Perestrojka 2.0 follows the day after, forget either Russia or Ukraine permitting this.

Much could be written here, but remember that writing software is in general both a time- and planning- intensive endavour. It occours to me that those who claim "Currently the CPU is the main bottleneck (you run into both as bottlenecks, even with top-end hardware), and for GPU performance, ED should focus on improving their software altogether." have never really served in a administrative capacity. If ED focuses on CPU- improvements alone, then when the GPU solely becomes the main problem, it will take years to start any meaningful work on it. Those developments have to progress parallel, and there is no point in waiting too long with certain decisions either, as those drive further R&D and its schedule. Many projects that ED releases now, are actually going far with regards to work began, and even further when it comes to planning. I haven't even touched upon the subject of what the competition is doing (I imagine that what is implemented in DCS, is likely a easy transfer to MCS), and rest assured, this is a central subject in this niche. As to the notion of where the improvements lie, ED knows that best. It is wrong for certain users to come and talk about improvements to the engine, and stipulate performance gains, when they've never opened and looked at the compiler themselves. At best, we know that with perfectly balanced settings, you can utilize both the CPU/GPU to maximum. How efficient those processes are, however, is only for a programmer to deduct. You cannot even compare DCS in this department to anything else on the market, because frankly, the level of simulation surpasses anything commercial by at least an order of magnitude, if not more. Whereas a helicopter blade will "MAYBE" be simulated individually in other "wannabe- simulators", here, we have individual sections of each blade simulated in real-time as you fly. All those hidden-to-the-user features cost immense calculation power. Hence, with everything happening beneath the ground, DCS is really well optimized for what it is - we really don't give it credit enough for it. While I am not a programmer myself, I'll tell you that the way it works, is that a programmer, using his/hers competence gives the company a couple of options with regards to solving an issue, and the decision is typically made at the administrative level, because this is a question of time invested, money spent and return on the investment. Not going too deep on this, but if e.g. further optimizing of DCS will cost 80% time spent for a 10% gain in performance, then what I present here, from the research paper to judge, is the exact opposite - 10% time spent for implementation, and massive, massive potential gains in performance. All at the behest of the final user. That's also why I'm focusing on the information regarding gains and positives/negatiives of the tech, but not so much the argument of this vs. optimization, because we simply don't know. Nobody outside the company knows. One final quick note; while I don't remember who (ED official) wrote/said it, or when (relatively recently) or where, it has been stated that the implementation of Vulkan will actually not yield as huge gains in performance, as many hope it will be. It's worth considering this statement. EDIT: Corrections.

There seems to be a serious problem, at times, with communication in these forums. Madman1, your whole comment is irrelevant to the technology presented here. MultiGPU has absolutely nothing to do with SLI/Crossfire, it also has nothing to do with purely workstation applications, neither can you make the assumption that "most" people have or don't motherboards with multiple PCi-express slots (practically every MB today that isn't ITX/mini-ATX is equipped with at least two PCi-express slots, most have three and north), nor does the MultiGPU rely on any drivers from GPU manufacturers... You need to properly read up on what is being discussed here. It cannot be that hard to open the documents that I posted and read, at the very least, the abstract. It's literally one paragraph. Come on people! At this point, I leave it to ED to decide whether they want to look into this more thoroughly. I literally don't have the time to explain things five times over on posts misleading the discussion.

Part of the optimization lies in changing out old technologies with new. This is why ED is going Vulkan to begin with. Also, the jump from a DX version to the next one has never yielded the performance gains you stipulate. There is nothing to support that DX12 alone will solve a noticeable part of the performance question. As to your second mention, I'll refer to the motivation listed in the paper. Apparently someone who has studied this very subject proves you wrong. A single person has been able to write a basic library and components needed in order to utilize the functionality of Vulkan and in that, bring technologies that were formerly restricted to the Pro consumer, to indeed the commercial one. Take a look at what I linked to earlier.

Indeed, VR is the devil in question here. Then even that becomes more mainstream. Look, personally, I support implementing technologies that might not necessarily benefit me. DLSS with in-app upscaling is an example here. It allows people with lesser hardware to experience VR, and great. For me though, it degrades detail too much. Given how complex and time-consuming programming generally is, one has to think way ahead in terms of what technologies to implement and based on predicted development of the sim. Funny enough, original HTC Vive, was the only VR I was ever able to max out (1080ti). Ever since then, while GPUs get 15%-20% more powerfull per release (~ 3 years) on average, the release of new VR headsets and implementation of new features make the demand rather exponential. In particular, if you look at this generation, the main technologies propagated by Nvidia were further DLSS advancements (degrade your picture quality for better performance - in 2025 we call it a feature, pre 2000, this would be criminal). The other technology being Frame Generation - again, multiplying frames in order to trick the user, does not actually mitigate the still non-articulated frametime. This can be compared to a well known issue in DCS occuring for some users where their FPS is above 30 FPS (often above 80), yet when they look at the ground from cockpit, it jitters. To keep it short, besides the incremental update from e.g. Nvidia, there really are no new technologies that are implemented to mitigate the ever increasing demand from VR. Now, consider upcoming features like dynamic campaign, ever increasing rivet details on each new module, etc... We should frankly, as a community, welcome any performance- giving addition with open hands, be it CPU- or GPU- related. What I'm trying to get across as well, is that it isn't only a win for the top-end user. Remember that people here live in countries where the 5090 or even 4090 is not available yet, or ever will be. This technology gives us all new options.

Haha Well, as said, Bigscreen is on the way. If this was inplemented, even more reason to go with Shiftall. That said, while upscaling never will equal a pixel-per-pixel, it's amazing how good DCS starts to look even with pixel upscaling. As to the general benefit, consider that everyone earns here, especially people with weaker PCs. Not everyone here can run maxed out on even a 2D screen. If you have a free card lying around, it's free performance for you. You can get two 2080ti's cheaper than a single 5090, for example.

Well, some settings are GPU- heavy, som CPU. Consider this though; when MT was announced publicly, the idea was that we were supposed to be able to go from utilizing one CPU core to two cores. Last I checked, DCS can utilize even 4 cores (with less load on the remaining two). My point being that we are slowly, but surely, improving. With VR though, we've actually hit the GPU bottleneck. I can verify that based on my settings and observations from HWmonitor. The real question with this proposal, is that currently, some video-related options, still claim medium-/high- CPU demand. What if that load could be GPU alone?! This is all up to the creativity of the programmer. In any case, the measured results in the scientific paper speak for themselves - 80% utilization of the following GPUs. For reference, SLI/X-fire(Crossfire) could only ever attain sub 60%, and that, was on select titles (PR for selling the GPUs). Realistically, you'd be closer to 40%, and even that wasn't common.

What is enough and isn't is very individual. I'm currently waiting for Bigscreen Beyond 2e, and meanwhile am using the Meta Quest 3. In order to have any resolution similar to 2D monitor, I have to render the resolution 1.7x up. Even if I'd stay with the native resolution, and still keep many settings on medium or close to (view range, clouds, shadows, mirror resolution, +++), I still get the ASW to jump down to 45 fps. In particular, Ka-50 BS3 cockpit is a monster on the fps (vanilla high res textures), which brings the 5090 to its knees. We are very far away from "enough" tbh. Yup, money never was a problem for me. Time on the other hand... But that's me. The genius part of this implementation, is that it would allow to mix and match any GPUs from a manufacturer, and still have it working. You wouldn't be locked to say 2x 980s, instead, a 2080ti and 3090ti would work together. Pretty sure it would be a welcome addition across the community.