Search the Community

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