rogorogo

Any rough outline, impressions, expectations for and about the v3.0 timeline? Asking in earnest interest (not only) because of the QoL aspect of it.

hmm.. well on the most basic level... the real danger lies in repeating past mistakes... (as in technical mistakes). Eagle often does not seem to have a systemic, release based knowledge managment. And the Hip (which I do not have as a module) had its own bug problems concerning mass and weight (unloaded stated, slingload mass). Too often from an outside perspective core Eagle seems to start its thinking process from scratch over and over and not continously going forward based on properly accumulated and knowledge-managed processes. And while it took years - and a change in ownership - to seemingly change this approach, this "corporate entity character/attitude/culture/personality" when it comes to for-market productiona and franchise cohesion, who knows and who could tell what and how things are on the technical, the development side. But I think whoever said "how aged the Hip FM felt comared to the Hind!" was very right - when and if refering to how the Hind "felt" before the current state (so for at max 1,5 patches). And not about comparing rotary aiframes (those two are completely different in everything) but how the flightmodel in itself was far more sophisticated in translating the experienced, the airframe feedback, the I/O of that rotary (aka the Shaitan-Arba) within th confines of a flightsim. On the other hand, I watched some Russian primary exchanges with the relevant and airframe-knowledge lead function and had someone with the right sensitivies and knowledge translate and discourse with me about them. And from an IT/game/flightsim genre/devstudio/PM/agile/SCRUM perspective there were some things worrysome even in this secondary consumption of out-market coms. Refering to exactly priorly stated issues. It is also not something to be done often... there are more pressing issues in the scarce commodity of "metime" to allocate increments of said time to. But then again we see Eagle also cleaning up shop. Finally starting to get some guidelines established for the entire franchise. Defining core competences and global standards, like fe now missiles are to be coded by everyone and to what outlines (finally). Attempt era cohesion, roadmapping assets, territories, scenarios. Somwhat grudingly acknowlegde that PvA is the future of the industry. Looking at global industry standards instead of proprietary everything (and then resting 15+ years unattended) for the most basic and core technical functions. But again... that is a whole other level of discussion.. also fishing by hand.. in a muddy pond.. blindfolded. But what we can take away is that unlike some 3rd party participants in the franchise clear and properly communicated intentions beyond any ambiguity is not something we are to come across from core Eagle. Not in the english com-channels, not in the Russian ones. But again, anyone with earnest analytical intent should see the current state at being completely "off" (even seomewhat literally "off"). It almost screams into our faces as an issue. Just by direct comparison just within the scope of DCS blind of any fidelic comparision outside from "now" to "before". Just by looking at now 35s and 24s behave when watching them, on videos, in airshows, in demonstrations, in maneuvers. Just by reading books with open eyes and comparing to digital experiences and media. Looking at Berkut programms. Any experience in any rotary, be it as passenger, student, occasional or even one time "if you want you can now...". To what degree doubts or just a critical thought about a potential issue can be substantiated by what set of experiences, education, topical competences is again a secondary factor. Bolstering a descriptive expression, extending it maybe. But just trying suitable to point out an issue with proper assessment also holds merit on its own. Because a fact is a fact - and if the sky is blue its blue and to assess its colour as blue is just that. And currently the mass, the weight, the inertia is absent with the Crocodile. Currrently the AP Heading channel (H-channel for НАПРАВЛЕНИЕ, and being the "yaw" channel) randomly starts going to max in low torque scenarios or just behaves plain bonkers. Currently VRS still happens as before with zero symptons, .. but falling out of the sky feels like in wadding instead of a stone dropping (or 10 tons of it) Currently the nose just noclip reacts. Currently every touch on the joystic (cyclic), just the weight of the hand on the throttle (collective) causes an immediately noticeable effect. Curently every reactive, every catpure input causes overreactions, oscillation buildup in everything (inputs, behaviour aso) Curently torque autority loss happens at the most awkard moments Currently any hover any bank any maneuver the Croc twitches randomly around and out of it and a lot more And anyone being properly attentive is qualified to point that out, is qualified to notice. And looking up the sky is still blue (actually is in this very moment), not neongreen, not ironman-skinned, not tesseracted. And my teacup has mass and weight and does not noclip float up from my desk

yes... that is very... surprising. Because this sudden complete absence of mass, weight, inertia, momentum (4 different things) means thins being absent that are especially relevant to this rotary aiframe. Its character and its uniqueness. But if you notice closely how those that see "no issue" describe how "everything is ok" and "but there is..." you quickly get the impression that they do not really have any familiarity with how an rotary aiframe, any of them "feels" and "behaves", how it translates inputs an communicates is movement.. and how this feeling, this impression can be recreated in a fligh sim. This can be unfamiliarity, this can be being completely uncritical, or just focus on completely different aspects instead of fidelic flight. Many things. If one were to did deeper we would probably soon arrive at very memey actual references and cognitive mappings, often. Even in this thread you can find very exemplary reactions. But that is human nature... not everyone has the necessary cognition, or the interest for a more removed, intersubjective assessment of an issue, the capacity for necessary extrapolation, the often weird twists of experience translation in different media (fe RL and a FS). Also please do not forget that contemporariy many people, way more than before, especially in "gaming" prefer "being right" or even "being a confirming echo iteration of any dominant message" over factual gnosis. Also... never underestimate social peer group dynamics. What matters more imo is if the product provider being dedicated to maintain the proclaimed fidelic scope of the product and not twist it to something else for marginally more sales potential in perception. And that has always seemed to be the case. But therefore there were other pecularities, especially in communication (upstream and downstream). Which is why getting the message across, raising awareness, especially from the english speaking channels is even more difficult, and the intent (as I tried) has to be expressively stated - in the absence of proper widespread consumers "noticing", the absence of spontaneous "problem consensus" in a fractured-by-its-very-nature consumer voice of diverse and often conflicting (in goals) interests, preferences, priorities, perceptions. That one sentence "before it felt like a big tub of..." describes the Shaitan-Arba quite well, and I would urge you (and anyone else acknowledging the topic) to please contribute to the bug description I linked, as extensively as you can. I think this the best we can do, to raise awareness in proper channels without the taint of opinionating.

you are very very right.. and it also may be a bug. We should hope it is a bug, because this is not accurate, not fidelic, not anything at all - especially when compared to before.

Also well yes, of course, and I am VERY much aware of that. Which is why I constantly and extensively typed that this sudden and violent Ux and behavioural change cannot have been intentional, it just reeks (no other term) of a systemic behavioural downflow and outflow bug that must have a potentially singular source issue, a true "source bug" (that might be weird or an oversight, or a qa-re-merge nonetheless). The various "changes" in submodules, keylogs, components, systems however you internally call them are just too much all over the place, just not "in sync" with each other, not systemic enough. And yes, both the airframe experts, the system experts (devs) and the mergepersons know that way better... but there is no other way to bugreport this. To try to pinpoint the issue, and map out the symptoms - and the earnest impression of a technical bug, not a design change. And again, apologies for "it dont feel right" - but again "it damn done feel right before" . And thank you for taking the time to react publicly and acknowledge the escalation into proper channels.

Please believe me when I type at you: "the feeling you expected as translative flightsim experience WAS THERE and EXACTLY as you described in your expectation outline". Until 2 (well 1,5) patches ago. Something which I explicitly stated fe here and there: Which is also the reason for me typing that extensively about it (including all the typos on planet Earth) Well yes, of course, absolutely. But what else is there to feedback but a personal, subjective and as descriptive as possible impression - in the absence of any other predefined and disseminated roster or guideline to follow? Also to convey, to translate, to communicate the "perception", the "feel", the "module-Ux" of a 24-P within the confines of a flightsim is not a straight 1:1 conversion of tables into code and datamodels. And the enduser, the customer is the least qualified to define the translative measures necessary to be applied. Of course this boils down to "it felt right and even on the raod to perfect before" & "now it dont feel right" - but again, what else and how is there to raise awareness with except being as earnest, as intersubjective. as descriptive as possible?

you should not get a false impression: it runs for everyone, and moreso for anyone who can handle Syria or PG in any shape or form. Only for some it does give some microfreezes atm at the coastlines for those traversing at extreme speeds depending on preload and DCS proprietary shader settings (aso) - and for a minority loadcrashes in the very beginning for those who have not yet populated their DCS caches by multiple load attempts (mostly if DCS is running on an HDD and/or low and/or lowspeed RAM). None of which should be mistaken for a prevalent or global problem state.

volume?

hmm.. as I had time to do some more "testing" today, I need to add a few more impressions. Not to "bump" this thread but just because being attentive to the initial observation made me notice some things that are even somewhat in contradiction to my initial observation. While again "testing" as in "just flying" a scenario which forced me to hover in a certain way (confined space, from higher up and limited crab approach and descent circle options) and not giving me a "way out" I felt even more of my initial observation to be true.. just in a different manner. The "sudden and fatal VRS" is still present but as the feel of weight, mass, intertia is gone while hovering has now become too "twitchy" I have to pay more time increments glanicing positional and even less increments available to watch the VSI. Thus if I actually have to hover down in a tight space from higher up without an open crab approach... both the hover spins out constantly with me working against the "joystick stir" instead of hovering against the airframe mass while the "VRS of doom" now manifets as before.. and maybe even more ninja-like, ESPECIALLY since now miniscule cyclic input have too much effect on the airframe where before you had to make conscious cyclic decisions with properly delayed airframe behaviour. The nose is "too light" and miniscule attitude changes because of miniscule cyclic inputs have far too much consequence even without the added current state of the collective inputs and the power output. Especially noticeable is that compared to before now way lower collective settings have to applied to achive negative VS/sinkrate than before -> helium ballon in gusts of wind feeling without any weather effects present. Even the VRS effect itself - while still sudden, no symptoms and always fatal - feels in immersion less like "a stone falling out of the sky" than before -> again helium ballon in gusts of wind feeling without any weather effects present. Same for the collective input. The hover process is also way more twitchy and inconsistent with sink rates being not as stable and controlled and the collective just being too reactive when it comes to "power output for VS". Thus miniscule cyclic can lead to completely weightless displacement instead of an actual "hover" behaviour, with proper corrections not correcting but stiring up out-of-control like an increasing oscillation wave. Thus the cyclic and even the collective in critical conditions feels like a QUERTZ quicktime event instead of a proactive and reactive conscious input decision. Worse, the hover transition is now very problematic when it comes to the relation of nose attitude <-> cyclic <-> VSI/angels. Not only do you have to use far less cyclic and attitude then before while minscule changes in either or at least in cyclic have far too immediate and noticeable effects, the hover transition itself now only feels controllable in forward transistion, where the proper and fidelic speed curve or descent circle constantly twitches out of control or the tail rotor loses authority (torque authority loss) or the heading channel of the AP suddenly goes to max for zero reason (well.. for the former mentioned torque issue). What is so disturbing about it is the the airframe twichting out of any curve and bank LEFT - the side the airframe is know for to be its "better side" and even the canopy visibility of the pilot-commander optimized for it (in a very rare instance of soviet russian consideration for any form of "ergonomics"). Moreso since this is also happening at speeds and with continuous flight intention, where the winglet effect was fomerly very noticeable while now more torque is commanded by DCS and it still suddenly twitches out without any soundmapping or any other fidelic symptom (aka the "heavy but stable in forward motion" translative feel is completely gone). Again, this is not like the airframe behaves (not IRL, firsthand- and/or secondary-narration consumption, not in its DCS translation, not with the necessary changes to convey a flightsim experience in any potential iteration) and not the same level of fidelity it was able to communicate within the confines of DCS in earlier patches. And yes, this reads completely subjective and it is - but how else should one describe this when there is no objective telemtry, no QR codes, no proper logs, to submit. I will not even attach a trackfile, or 5 actually where I tested this, as it would not contribute anything (also: trackfiles in themselves are not that reliable for replication as we all should know and its boring to watch me fly around badly long just to VRS in the very same situation just slighty different over and over). The conditions are the same, the extra description is made as a separate comment because of me forcing me into a replicable scenario for myself. I cannot be the only one noticing this.. and while the reason as in "source-issue" could be anything, even just weird AP or trim behaviour, typo-related-bugs, missing or not interacting variables.. this is a major impairment of the module behaviour imho. Again... I cannot be the sole person to notice this.. I hope.

indeed it does, which is - as bug-reported for 3+ patches now - odd. While the mechanical solution for the trim are more or less hydraulic actuactors in the 24-p arresting the cyclic and the torque pedals (part of САУ-В24-1 - "Cистема автоматического управления" - Automatic control system), those very AP channels (ВУАП-1 - Вертолетный унифицированный автопилот [Unified Helicopter Autopilot]) are the actual electronic component of the Trimmer system (actuating the cyclic and the torque pedals to achieve/maintain trim states as mandated against outside condition changes). But this might be either an isolated bug or just a buggy downflow-behaviour since the latest patch seems to have a general FM issue as I tried to describe here: But the "trim overflow", the occasional "cyclic-lock" with still working hat-trim across all 3 peripheral modes has been present since the first early access... if only if only there was a proper bugtracker for this to get actually looked at systemically (and if there was a will to do so... instead of this tendency to too often register bug reports as offensive operations to personal sensitivities and attitudes.... Eagle really is still a very very strange corporate entity... sometimes...)

this is the SuperCarrier Адмирал флота Советского Союза Кузнецов, it has working blast-shield animations, is retextured, working radar and secnet arrays, working animated wheelblocks integrating with the Su-33s stageII burner, different approach messages, approach ligthning and animations aso aso aso.. and the firetruck is gone ( ) . It came with the SC module, is a module-exclusive and was the reason everyone got an Su-33 with the module account-infused (fe I now have two). And you are very right, almost everyone attending your extremely well thought-through and balanced for the current possibilities within DCS-MP server will have the module, moreso if interested to use carrier-based aiframes.. and the inevitable statistical minority that does not still has enough alternatives in every mission.

I must add something to this OP as a separate comment. After having tested it again with a further - single player and campaign - mission there most definitely is a change to either inputs or FM that caused a bug (probably a typo or a repo-merge oversight). Forward facing transition to hover is now far too easy, even while almost completely staying level and at neutral angels. While IN hover I now constantly have to play with the collective and "stir" in the cyclic in miniscule corrections on all 3 axes (including rudder/torque pedals/tailrotor) - as I use sticktwist and "rudder trim" because of it the hover can far too easily twitch out.. in low speed and hover envelopes the hind suddenly does not feel like a shaitan-arba or a crocodile but a floating twitchy noclip camera (no exaggeration) where the challenge is not to hover against weight, mass nd inertia but to keep the cylic-stir under control the tailrotor now tends to lose authority far to easy in takeoff and final hover, same in ground effect and on pad/touchdown as described above pad-landings and hover landings in general are now far too eas, too precise and effortless for a 24-P (despite the wheels soapgliding and the tail-rotor authority loss). This was far more fidelic before minor collective corrections now suddenly have a massive noticeable impact in a relative short amount of time (again hinting a loss of weight, mass, inertia - maybe just a typo that commented out mass-variables?) arrest-curves are now trickier than forward arrests and transitions.. again 86-ing the correct behaviour for the airframe and reversing priorly present fidelity Attached a second track showing the issue on both pad-landings. I have yet to test this in a multiplayer scenario (if input lag changes anything) - but the Crocodile felt extremely fidelic and akin-sync in both scenarios before. And anyone who has even seen an Mi-24 or a 35 even in an airshow should notice that this there is something amiss here... especially to the correct and fidelic "feel" and behaviour before (where again -> getting the inertia, weight and mass under control and in transition was a correct and fidelic challenge, despite the far too-sudden-without-any-symptoms and always fatal VRS). Especially on the final landing in the track... while before I would have crabbed in slowly I was now almost freezing and gripping on the cyclic as to not twitch out of the crab approach . while feeling weightless as a feather in player-immersion-uX that I could have just arrested and dropped straight down. Again.. there is most definitely a bug - because if this is intended behaviour... the behavioral characteristics are now "just off"... completely and bizzarely "off". For the passer-in-glancing, please focus on the bug behaviour, my bad flying is a given having to be seen as "baseline" . Trackfile as google link as it exceeds attachment limit: https://drive.google.com/file/d/1GW2CxWUZrzw2EZ8fcxTXsjyX6U727R1w/view?usp=sharing P.S. this went so far I even dismantled my stick to check if the magnet- and srping-mods were still there and working correctly.

patches 2.7.4.9632 and 2.7.4.9847 have introduced various fixes and tweaks to controls, trim and FM. And for the most part they seem to have been very sucessfull (fe the problem with "overtrim" are far less and the sound feedback is also very helpfull). The Shaitan-Arba is now also much more controllable at low speeds. Especially noteworty in a positive way - VRS does no longer suddenly and fatally happen, the soundmapping for RBS, VRS, max-envelope aso is now a completely suitable indicator. What seems to need further attention is the following though: the feel of weight and mass now seems reduced, and the Hind is too twitchy in various envelopes (to the point where one seems to "stir" the cyclic aka the joystick) while hover transitions are now far more controllable the hover itself seems to have become very twitchy even in low-weight and zero stress conditions the wheels now "soapglide" even more in almost all terrains, even with collective on zero, rpm throttle down, and wheel brakes locked I have included a track from the remastered-for-hind huey-campaign (ty for that excellent scenario to really control the Hind @Bailey) where this can be seen. I also could directly compare the asset behaviour to before the patch (as I had just flown that mission before both patches). Twitchy hover: during takeoff at final landing at "Madrid" at the end "soapgliding" of wheels at rolling landing and taxi at Senaki-Kholki on the pad at "Madrid", with various test of AP channels, locked wheel brakes, applied wheel brakes, idle rpm, zero collective, diverse trimstates "rudder" (tailrotor), "heading" AP channel on/off slights osciallations during flight in stable envelope with no input entire flight various attitudes, crabbing during transition during speed hook or forward reduction notice zero control input (control input indicator up entire track) notice "pulse" inducing oscillation with slightest inputs as if input signal is registering on/off For the problems describe above, also notice how for the most part non-pilot induced oscillations seem rock stable while any attemopt to correct them with minor cylic, minor collective or general slight(test) peripheral input seem to surge the oscialltions or the twitchy hover behaviour (especially noticeable at the end of the track, when I almost crash myself at "Madrid"). The widely reported "overtrim" or "input overshoot when pressing trim" is reduced but still noticeable. For the passer-in-glancing, please focus on the bug behaviour, my bad flying is a given having to be seen as "baseline" . Trackfile as google-drive link as filesize exceeds attachment limit: https://drive.google.com/file/d/1u71lvSaImScYA2f3zgynpGPhEwe5roFX/view?usp=sharing Dxdiag file attached for good measure. DxDiag.txt

Be aware that when you enter RBS there are also different scenarios how to recover depending on the if and how many of the AFI-channels ("autopilot" that are actually the AFCS-dampener-assist channels) you have enabled. Also be aware that for VRS and probably in an nuance for RBS the transition is or might not yet be fully modelled (aka behavioural hints).

and additional track showing the glitches at all angles in a multiplayer scenario (Aerobatics Europe Marianas Islands Server). As the track is 50 MB, google Drive link: https://drive.google.com/file/d/1oH1eqo0kRVkyJDR5AsaGKWJMzWGYHSbL/view?usp=sharing All glitches at all angles with all and only x,y,z offsets tested in multiplayer - WITHOUT using zoom function - after takeoff and trimmed flight from ROTA to Seawise Giant WNW. In-flight also hints at problem when campoint glitches during insertion/combat/defensive/challenging maneuver in weather or conflict. System: Delanclip opentrack 2.3.13 Logitech c270 webcam using TrackIR protocoll all drivers updated, WIINX updated latest CAB and updates, AMD GPU latest WHQL package 21.6.1 dxdiag attached if needed DxDiag.txt

well, you can call it personally what you want, as long as you explain what you mean (every single time) - it just does not change what it is or what (most) of the people involved in the gaming industry (yes, gaming industry, I can't change that as much as the sky is blue when its sunny.. unless you are in Beijing, the absurd smog does weird things there) will label it (but fear not, E-D and most of their third parties are quirky enough to make everything very confusing). Also what is a "VR body" if one does not use VR? Or is "VR" a personal, subjective interpretation assumed to be "clear to eeeeeeeeveryonnnnnee.. HERE!" too? But again, you did not instigate the topic, so feel free and you do you (really). But back on topic - the <<insert term of preference here>> is also not headless per se. If coded with an inner and outer render model and a floating cam-point is used with the absolute zero in the middle of the head the inner render is commented out and the offset floating from there. And from there the variants roam free (effort, time, budget,....) It can be a unified render model with the cam point glued to an eye and offsets disabled by hardset override. It can be a limited cam vector tied to head and upper body limits. It can be an animated body with offsets corelating body animations and maximum movements (one contemporary product even has your butt slushing around in the seat if you go y-down with a hard max). And all of that with or without zoom (the actual zoom which is just that - zoom, not movement along the z-axis). It can have all of the above but no resolvers. Or no hardsets. Or all of the above and so much more not mentioned every anywhere by anyone unknow to most that are everyone but only almost. And anything in-between. Given what module this is about (the sole and only reason I ever looked at DCS btw)- all of it highly unlikely as time and budget would be rather difficult to allocate for yet another module-specific solution in what should be a franchise-wide unified standard in the first place (as so many other and quite relevant topics btw) imho but one can always hope and hope dies last I have been told. And as we are consumers, not creators, not developers, not multiplicators, fractured by our very nature of diversity, preferences, moods, constraints - we can express product wishes, desires that might or might not get realized (hint: if we all feel equally unsatisfied then in the most competent way actually - cognitive dissonance und so weiter, gell?). The - safe, quite comfortable, effortless and subjectively instantly rewarding - alternative is to just echo something unspecific at each other, or even the lowest and/or safest denominator, or even be lingustically crowding out from the safety of a one-way bubble while revelling in proactive auto-shunting (hint hint wink wink OP) - but whether to simply go "mooh" or don a tutu and dance in front of a street organ does not matter, it will only result in fractured voices not being heard save for being a pretense for something. If you are fine with that - jo mei, passt ah, woarad ja neds erste ors lezde moi göööh ?

? Well.. good for you and the entire world you have interacted with and reached consensus on about that. But you are not typing this for your perceived "everyone" - you are typing an OP and every contribution for the actual everyone. People who might be new to DCS, people who might look something up and don't usually participate, people who are unaware this forum exists but find the topic via a google search. You type it for devs who might talk internally about the if and the how to do this, or not. You type this to not provide a pretense for other devs who might look for one to not greenlight something, or not seed a global standard in-suite. So you always have to be clear, precise and beyond ambiguity if you start a discussion. And if you do not want that, you are in the end only diminishing yourself and everyone else of opportunities and chances for product improvement. As much as by the how and the what you, me, we type you, me, we, all of us control the tonality (mostly) when instigating a topic.

this is a bug, randomly when you trim, all controls are locked and stay locked - not the case in the OP-bug... but there is a bug that is not the bug that is actually present in "central position timmer mode" AND "default". Sometimes the controls will stay locked/no inputs will be registered (weirdly coolie hat/PoV Hat trimming will still wor) - not matter where to controls/inputs are returned or the stick is let go off or input is given on any axis. The only way to resolve that bug before crashing is pressing "trim reset" and get the airframe back under control (retrim). It happens randomly and is - like the "trim overflow" - definitely a bug and not intended or mode related behaviour. Again - not the case in this OP though most likely.

resoning for the addendum of alternate English labeling: The uneasiness of labeling the entire AFCS suite components with "autopilot" is present in many modules of soviet-era/russian origin. And while this is absolutely correct in Russian language and in extension in direct translation, it creates a contextual problem. In the case of the hind - or in russian engineering terms in general - the system suite is referred to as "ВУАП-1 - Вертолетный унифицированный автопилот", which correctly directly translates more or less as "unified helicopter autopilot". But if we look at the parent umbrelly system component we already get a hint about a linguistic issue. The parent component is the "САУ-В24-1 - "Cистема автоматического управления", the "Automatic control system" that by description includes the (wait for it) "autopilot" (refering in this case to the autopilot and the AFCS in one word) and automatic navigation system. So again, if we were to just directly translate, all good. But there is context to be considered. Russian is despite pop-cultural perception a quite poetic, nuanced and contextual language (for the latter weirdly a little bit like the English language) and can be quite efficient by defining meaning in context with a few multiapplication terms. But when we take the engineering culture into consideration the "autopilot" in English language engineering terminology and culture has a distinctive clearly defined functional meaning, while anything related to automation, input dampening, thresholding, stablization and assist is labelled with anything from "AFCS" to "dampener". So is the case with western/NATO engineering culture in general, be it in a technocratic and distinctively descriptive language and terminology like German (no naaah....) or anything in-between of rhaeto-roman languages (fe French, Italian.. hmm.. now the spanish and hispanic world will hate me too, but poor me no es bueno en enspanol). Because of that, a simple direct - while precise - translation fails to purvey the functional character descriptions of Russian source terminolgy for the component. This is also the case for other modules, but those are low-fidelity so imho a little futile to point out (but! - full fidelity Mig "29er", we should all take notice"). We even get a direct statement if the just read the abstract description of the ВУАП-1 - Вертолетный унифицированный автопилот, which reads "Предназначен для улучшения пилотажных характеристик вертолета на всех эксплуатационных режимах полета, а также для автоматической стабилизации угловых поло­жений и демпфирования угловых колебаний но курсу, кре­ну и тангажу". It literally states that the system is there to "improve piloting characteristics in all flight modes and for automatic stablization" - the very essence, function and description of an AFCS dampener and stablization assist system, not an "autopilot". So again, imo while автопилот is simply autopilot as an insular word, it "means" something different as soon as the word is combined with contextual terms like унифицированный автопилот or ТАНГАЖ канал in expression. And as the labels and overlays should be descriptive, unfiied, clear, precise and beyond ambiguity - the true meaning has to be expressed in translation, not a simple (although no less precise) word by word translation without context or topical sensitivity. P.S. No, I am not fluent in Russian, after thinking about this and doing some research I then asked a Russian engineer (among other things) who is fluent beyond conversational level in English and intellectually capable and sensitive in and for the linguistic aspect of the topic (Also.. smart, beyond average.. and median) about the validity of my suspicions.

The mouseover labels for the Autopilot Channels in the ENGLISH cockpit are currently labeled as follows: Autopilot H Channel ON/OFF Autopilot K Channel ON/OFF Autopilot T Channel ON/OFF Autopilot B Channel ON/OFF And are also labeled as such in the Control Bindings, clearly derived from НАПРАВЛЕНИЕ, КРЕН, ТАНГАЖ and высота for Yaw, Roll, Pitch, and Altitude. In-cockpit there are top labels describing the actual function of the channels: but the bindings line items are - as described above . labeled like the mouse-overlay and look like this. This will inevitably lead to confusion Thus in consequence the Mouse overlays AND control line items - should be relabeled as follows: Autopilot H Channel ON/OFF -> Autopilot YAW Channel ON/OFF or AFCS YAW Channel ON/OFF Autopilot K Channel ON/OFF -> Autopilot ROLL Channel ON/OFF or AFCS ROLL Channel ON/OFF Autopilot T Channel ON/OFF -> Autopilot PITCH Channel ON/OFF or AFCS PITCH Channel ON/OFF Autopilot B Channel ON/OFF -> Autopilot ALT Channel ON/OFF or AFCS ALT Channel ON/OFF Reasoning: in time many players/user/purchasers will start turning those channels on and off in-flight in various combinations to enjoy the true extent of the flight model and the visceral experience of the Mi-24 that is very impressively translated in the module and also enables more elegant and fludicic, precise maneuvering that is just.. well.. Hind-like (a rotary oiltanker, or freight train), while the dampeners are very much needed in the hover-takeoff and hover-landing phase. Thus the labels for mouse overlays but especially control line items in the English cockpit and UI-version should be precise, simple, clear and beyond ambiguity. Addendum: Also the term "Autopilot" is ambiguous or even misleading as they are actually "AFCS" (Automated Flight Control System) or "Input-Dampener/Stablilizer-Assist" channels. Therefore I have added alternate relabel suggestions addressing this issue too. Again these applies to the mouse-overlays and/but especially the control binding line items. The actual "Autopilot"(s) are "only the Hover/Altimeter/Route functions that are the actual autopilots and the only one that should be label as such in the bindings. Trackfile showcasing the overlays and cockpit labels attached. ap_channel_labels.trk

correct track added in OP, my mistake, apologies

added correct track, my mistake apologies! headtracking_xyz_box_confines.trk

DCS currently uses a floating cam postion for headtracking, not a fixed campoint tied to a rendered pilot body (actor) with animation resolvers (afaik). In the Pilot-Commander Station this causes the cam-vector to often glitch into the rendered airframe beyond the station confines. Attached track shows the glitches purely using the x,y,z offset axis (head movement) and enhancing the issue with the zoom axis. Also noticeable: the x,y,z confines are hard set for the side-door (cam cannot "lean peak" outside forward even when door is open) are not set, not set enough, not present when looking over the shoulder (rotation 180°) plus lean forward (x) are not set not set enough, not present when raising head (y) This is a relevant bug as the cam-vector tends to glitch through the airframe in emergency maneuvers, overweight hover situations, combat maneuvers where it is most distracting and a recenter is adding to "having ones hands full", while immediately glitching back. I am well aware that this is tedious work (another box) but as there is no actor subsystem to tie-up on this may have to be listed up as the player-view-cam is a vital part of the module loop. headtracking_xyz_box_confines.trk

"Petrovich AI Auto Handover" checked in the "special" tab?

and naturally - after an evening of futility.... this evening the dampeners started suddenly working, the dampeners gave diamond feedback, the in-module cyclic had the correct offset in render when the dampener trimmed it (motor servos to hold it in place). I need tea.. and maybe a hug. P.S. Now I can happily crash due to my very own vast incomptence