Search the Community

Dear ED developers, I’ve been your fan since Lock On days and have enjoyed DCS for at least 8 years now. In the past year I’ve detected some strange behaviour on fox1 servers regarding Aim-7 performance. I’ve been more active in recent weeks and the issue seems too severe to be ignored. Being a professional analyst (and ex low-temperature physicist), I know that opinions and feelings count for nothing in these cases. After dedicating 30+ hours to solving this issue, I believe I’ve successfully identified the problem and see an immediate solution to mitigate it. Let us dive right into it using numbers and physical quantities from TacView, as well as known missile parameters thanks to dcs-lua-datamine github by Quaggles. The key date is 11.7.2024 - on this day, everything changed with the whole Aim-7 family. Despite my best efforts, I haven’t been able to collect Tacview files closer to this event, but I can demonstrate the change using one from 03/2023 in the “before” period and a more recent one from 2025 in the “after” period. When we compare Aim-7M performance before and after the change, it is both qualitatively and quantitatively different. I am using Tacview Advanced graphs and the metric of choice is total mechanical energy. Not only is the maximum energy vastly different, but also its time evolution (character). We know that Aim-7F and above are dual-stage. First, the booster lights up, delivering the strongest impulse. After that, the sustainer rocket motor kicks in, delivering the final bit of extra energy. In the before period (scenario A), the Aim-7M missile gets to its maximum energy only after the sustainer phase. However, since the change (scenario B), the missile reaches its maximum energy state already after the initial booster phase. Sustainer then merely preserves this energy for the duration of its burn. This is the qualitative change. There is also a quantitative change. New maximum energy is more than before. So not only does the missile reach higher energy faster, it can also preserve it in a superior way (see attachments). The following thing shouldn’t be considered a “proof” of any kind, merely a supportive argument. I formulated a question for ChatGPT and got an answer, that scenario A is much more realistic for the Aim-7 missile (see attachments). Now, for the actual proof. I was wondering for some time, what could possibly be responsible for such a dramatic change in missile energy management. With the background in physics, a few things immediately crossed my mind. Either the magnitude of the impulse of at least one of the rocket motors changed, or the delivery character of that impulse (its time evolution) or the missile’s mass (weight) itself. I went through the whole changelog since 03/2023 and curiously enough, found that on 11.7.2024 that’s precisely what changed - but for the E and E2 variants. See: https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.6.57650/ Look for: “Weapons. AIM-7E/E2 mass decreased.” From that point on, it all started making sense. I discovered this brilliant guy’s Quaggles github, pulled the commit from 11.7.2024 and the earliest one before this date. Started comparing all Aim-7 variants before and after. Soon enough, I stumbled upon the culprit. Link for the latest commit before the change: https://github.com/Quaggles/dcs-lua-datamine/blob/e57755713d8ae6b59ccf1831b089e3b33aee7633/_G/rockets/AIM-7MH.lua Link for the commit right at the change (11.7.2024): https://github.com/Quaggles/dcs-lua-datamine/blob/da69a9f560550da346501f4056261e491ac4079a/_G/rockets/AIM-7MH.lua Let’s have a look at some of those missile parameters. Of course, I am not an ED developer and cannot possibly know what these parameters mean, right? There is no official documentation, so it could be air temperature. Well, yes and no. Thanks to your changelog, we do know that the mass of the E and E2 variants did change on 11.7.2024. When we compare the changes specifically in the E2 missile files, we find only 3 changes in all the parameter values. We know that the mass is supposed to change and we can see 3 updated parameters. Can we safely assume that these 3 parameters define the missile’s mass? For the sake of this report, let’s call them “index M”, “fm mass1” and “fm mass2” (see attachments). For your convenience, I have provided a table with all existing Aim-7 variants, changes of these 3 parameters in the aforementioned commits and verified that the parameter values have stayed the same right up to now. We can immediately see the problem: missile param 23.3.2024 11.7.2024 30.6.2025 Aim-7E2 index M 230 194 194 Aim-7E2 fm mass1 231 194 194 Aim-7E2 fm mass2 230 194 194 Aim-7E index M 230 206.4 206.4 Aim-7E fm mass1 231 194 194 Aim-7E fm mass2 230 206.4 206.4 Aim-7F index M 231 231 231 Aim-7F fm mass1 231 194 194 Aim-7F fm mass2 231 231 231 Aim-7MH index M 231 231 231 Aim-7MH fm mass1 231 194 194 Aim-7MH fm mass2 231 231 231 Aim-7P index M 231 231 231 Aim-7P fm mass1 231 194 194 Aim-7P fm mass2 231 231 231 Aim-7(M?) index M 231.1 231.1 231.1 Aim-7(M?) fm mass1 231.1 194 194 Aim-7(M?) fm mass2 231.1 231.1 231.1 First of all, before the change, for every missile, all 3 of these parameters were kept the same (only difference = 1 with E2 variant). After the change, only the E2 missile has equal values of the 3 params, all of the other missiles have 1 parameter different from the remaining two. The most dramatic difference is 37kg. Not only is the parameter different, but it is exactly the value present in the E2 variant (194). Is it possible that somehow, at some point, the E2 "fm mass1" value overspilled to the other variants? Commiting different versions of the code, copying the value of the params, etc.? I am 99% confident that this is not the change you'd intended to do. Because you did change the values for E2, but kept all 3 params the same. That appears to be the correct approach. It is my suspicion and hypothesis, that this one single parameter is directly responsible for the new buffed-up missile performance of the variants that shouldn't have been changed at all. There is one more supporting evidence for this. E and E2 variants should have different mass according to literature and also according to your changes. The difference should be about 6% (194 vs 206.4). There are more differences in missile params for these 2 missiles in the "seeker" and "autopilot" part and it was my hypothesis that these could be ignored when firing blind without a target lock. We tested it and arrived at an estimated difference in gained energy of 0.6% - this is nowhere near the perceived mass difference. In the "boost" and "march" parameters, they have the same impulse value. So the motors are the same, the impulse is the same, the resulting extra speed should be different by about 6% (p = m.v), but it's barely detectable (0.6% diff in energy) EDIT: I may be wrong at this point. After comparing missile speeds, the E vs E2 may actually have about 5% difference in speed, but it's hard to judge. The aircraft shot one missile at slightly higher initial speed. Combined with drag being dependent of speed etc. this creates a difference. And also the other extra missile parameters, in which these missiles differ, could play a role. Attached, you'll find what I believe to be proof that these missiles actually have the same mass for the purposes of energy after launch. Despite not having same mass in real life and also in the other 2 mass parameters. EDIT: hard to say. They appear too similar. This is all I can provide at this moment, I'm happy to talk more about this. I only have few key questions for you and would be delighted if you managed to answer them: 1. Can you please confirm, that you indeed observe the provided values of the parameters and that 1 ("fm mass1") is different from the other two in all but the E2 variant? 2. Can you please confirm if this was unintended and the idea indeed was, to keep all 3 parameters at same (updated) values? 3. If yes, am I right in assuming this could be fixed as easily as rewriting one parameter value for 5 missiles to match the remaining two parameter values? 4. And finally, if yes, could you please prioritize this in your future updates? If you've survived to the merge (the end of my post), thank you and congratulations. I wish you the very best of luck in improving and maintaining the game that we all love and enjoy so much. Best regards, Merrek

Before I type my bug report - a positive note. The latest patches have introduced an enhanced fidelity if the collective blade pitch is changed either for the airframe reaction and orientation. Not only the nose or airframe vector but also the entire tilt and drift change in a very fidelic way. This is especially noticeable if the КРЕН and ТАНГАЖ dampener channels of the ВУАП-1 suite system are in use, and the НАПРАВЛЕНИЕ dampener channel and the высота maintain channel are turned off. This is a very positive sign and I hope this is a small symbol about the intent to have a fidelity gradient for this module this iconic rotary frame deserves, Now for the less positive - aka the bug report. Unfortunately the situation described in this bug report: and especially in its mysteriously vanished parts have worsened and are now clearly a more systemic issue that is a culmintation of various (in parts acknowledged and already being worked on in insularity) issues that cause cascading issues. The missing weight (mass) and inertia is leading to more oscillations, especially with a "light" configuration (less fuel, light munitions load) that is itself problematic during a terrain final (hover) on non-flat "terrain" surfaces. Clearly noticeable is now that the DCS trim settings ("control helper" or "special tab" options) of "default" and central position are NOT reliably working during any instance, even within the same DCS client session. Further the INGAME settings of "AP trim" (trim button setting) and "manual trim" (fe coolie hat) seem to cause cascading issues in the game code, resulting in more and more offsets to the point that even a full reset result in progressive input necessity and corrections (cyclic stirring). On top of this the constant exception catcher events of the DCS proprietary settings result in more and more input necessity during a longer flight (no reinit of airframe and or world load). Another sympton is the drift-gauge suddenly showing random indications, while the player can notice the airframe behaving completely differently. Sometimes this even results in mirror indications of what is going on or the gauge switching from random left/port-right/starboard indications with the airframe having a TVI in an entirely separate third orientation. On top of all of this there seemingly is a threshold where - again as reported before - VRS seems to suddenly occur like a trigger event (the attentive enough can even see the airframe frameblink before the VRS effect kick in as if an ingame event was triggered). Where before VRS might have been recoverable, it now is an unrecoverable disatrous quicktime event.. even if this even occurs already on the ground or at 1-2 m AGL. More disturbingly this event can occurr in a stable hover and a sinkrate of -1 or -2 on the VSI (radar alt on) and the Doppler-hover system working. So apart from the bug state in each part mentioned, there is a cascading interaction on a systemic level. If the results are caused by this cascading interaction cannot be judged by an enduser and it evenly shows the possibility of an unerlying fundematal source issue causing said interaction or even gradients of the insular bugs in each keylog submodule. Which could be the clearly hardmodified weight variables, the currently missing physicalized inertia, anything. That there IS a bug can not only be noticed by the osciallation issues, the VRS states, the inability to trim at a certain point (or the "trimlock bug) but also by clear exception catcher and outlier events. Example: if these bug in any subset have started occuring.. an RBS effect will result in the airframe rolling at 3-4 times the speed it would normally RBS roll to the right in a comparable, replicable scenario. Test scenario: Singleplayer and multiplayer with repeatable scenarios in direct comparison to prior bug notice x52 sets magnet modded, spring modded, zero signal stutter, controls cleaned (not double binding of active peripherals) trim setting (DCS proprietary) "central position" including "rudder" ingame settings as described above current workaround of constant "reset" and retrim from zero applied Dxdiag irrelevant but attached. Trackfiles: 2x singleplayer, direct comparison to prior scenarios, chosen because of drastic showcase and 8+ repetitions and chosen because of lean trackfile. https://drive.google.com/file/d/1ojlq_M56d2skyne8_9QmqmFvgFqcHZE2/view?usp=sharing https://drive.google.com/file/d/1ok5VXQnXas7UBmTQgEIrHr_4wcDA3e91/view?usp=sharing DxDiag.txt

Hello I would like to bring up Ataka weight. There seems to be some pretty widespread disagreement along online sources. Some say 33.5 kg, some say 42.5 kg (as it is in DCS), and some say 49.5 or incorrectly say 48.5. Upon further research you would find multiple sources claiming it is 49.5 kg in the container, whereas in DCS it is 57.5 kg in the container tube http://www.airwar.ru/weapon/aat/ataka.html However, the container is known to be 15 kg, which is what it is in DCS as well with the rack being 13 kg. This would mean that if weight in container was 49.5 kg, actual missile weight would be 33.5 kg. There is a textbook that appears to claim the only difference between Shturm and Ataka is warhead, “Конструкция Средств Поражения, Боеприпасов, Взрывателей И Систем Управления Средствами Поражения: Конструкция и функционирование ПТУР" (Design of Weapons, Ammunition, Fuses, and Control of Destructive Devices: Design and Functioning of ATGMs) by the Penza Artillery Engineering Institute.” And since the 9M120 Ataka warhead is 2 kg heavier then Shturm warhead, and Shturm is 31.5 kg. That brings you to 33.5 kg. There is mentions of 9M120 Ataka being 33.5 kg in this article written by Roy a Broybook in 2005, available here for free viewing https://www.thefreelibrary.com/Weapons+for+whirlybirds-a0138143048 It is also mentioned here as weight of the Ataka being 33.5 kg, but a source is not given. The many sources in the rest of the article especially including Shturm/Ataka make me believe there has to be some reason for the author to have settled on 33.5 kg. Surprisingly they also make the same 48.5 kg mistake for weight inside container. https://thesovietarmourblog.blogspot.com/2021/07/soviet-atgms.html?m=1 Interestingly enough there also English language sources saying weight of Ataka is 42.5 kg as it is in DCS. https://odin.tradoc.army.mil/WEG/Asset/9M120_Ataka_(AT-9_Spiral-2)_Russian_Anti-Tank_Guided_Missile_(ATGM) http://www.military-today.com/missiles/ataka.htm I don’t have much else to say other then, a Mi-24V IE manual makes it known that Ataka average speed is slower then Shturm. Currently in DCS, the Ataka has its rocket power slightly changed from Shturm, I assume to make up for the weight, wether that is based on reality or trying to replicate its real world performance I do not know. I only mention this to say that, if Ataka weight is lowered from its current 42.5 kg to 33.5 kg if ED finds that to be correct, I would hope that the performance still falls within the acceptable region for ED’s standards of realism. I apologize for all the bug reports, but as there seems to be a renewed push to finish Mi-24 and polish it. It seems this is the time to go through details and see if there is anything that can be made better