rogorogo

caveat: code can be deceiving. Just entering "correct" numbers does almot never result in "correct" representation in a game engine, especially in a flight sim, especially especially in a proprietary engine like the one of the DCS franchise (although labeling it "engine" is already a thin ice endeavour). Even if a product engine, any product, any engine is inteded to have 1:1 maintenance:representation coding, there will always inevitably have to be endless tuning. So to sourcetrack any issue we would have to know all factors and prerequisites of the causality chain, like (but not limited to): Eagle's code intent, solution approach and systemic cohesion concept (Eagle D <-> cohesive systemics.. lol.. good one ) DCS's engine behaviour and representation metrics vertical keylog subsidiarity behavioural function in- and outflow mapping Neither of which we have access to, for all we can know the correct numbers to enter for the intended representation (assuming that is the intent) could be "69", "666" and "wolperdingerfurz". What we DO know are soft factors, like the fact that especially HE fragmentation and explosive dispersion is modeled... hmmm.. what should we type... underwhelming? insufficient? odd? shorcoming?. Mostly as a result of the great tradition of zero attention for the longest time for anything unless ex-post of a matter-hits-fan realization (oh look ground asset models recently got a poly pass... but only here and there and mostly over there....gee.. I wonder why.. and why not before?). This can even reach module level, when anyone with one semester or even the faint idea to study BA or Marketing would understand all modules are to have the same scope and level and certain modules need special attention by necessity for a franchise scope and diversity and adversity balance. But here we are and here we will stay. Also this and every other discussion, while neat is completely academic. I can assure you that nothing gestated here registers at the end of the hallway of Офис 87 in 141983 Московская область and any information officially disseminated here is rather... freeform. And all the people with those yellow labels are mostly attention seekers in social media environments, herd animals going moooh for whoever and whatever (I refrain from typing 2 of the 5 actual media and gaming industry classification labels) neither doing any actual testing nor effluviating anything less safely dismissable than "official" anything (notable exception nonwithstanding, but exceptions are exactly that, statistical outliers non-representative of sample medians and centroids in a datapoint cloud). So would - despite the futilty - should we, as consumers admonish then? Well.. imho what we already have.. these rockets are not correctly represented. And this is the extent and limit of the admonishemt, supply correct sources, supply a problem outline.. and then rally and insist! to track the actual global source issue, not present a bandaid-fix. And in the process, it would be nice to also finally (after YEARS) adress (exemplaries from a very long list) things like: editor placeable beacons and NDBs not working role select screen server session table foliage fuse issue wipers and canopy rain shaders rain in general message and notification box cpu imprint multithread vulkan (beyond default) globalization of munitions behaviour globalization of radar systemics and behaviour globalized franchise standards in general But all of that, or any of that is as likely as world peace.

If you use them this way.. all is fine.. but you should fly a repeatable pattern - you will notice more drift with the map than would happen if you did not readjust. If you ever change map scale after you have readjusted map scale (which in itself is kind of weird.. it would be an exchange of the paper map.. and a different readout of th dopper logic, which that system can do... but not in flight and that much "on the fly" - also there should be some sort of animation and longer "pause filler" to represent what would actially happen irl for fideltiy) this drift becomes way more noticeable.. to the point where finding your way home if you do not happen to know the terrain features very well by heart can become an issue. So again the issue is that if you have a repeatable scneario - the functional behaviour changes after an event (in this case, re-adjusting the map). Which defeats the purpose of this function.. you do not have this feature modelled in-game for the "moving map" to become less precise after needing more re-adjustmen. The "moving map" imprecision behaviour should not be affected by this. Again the source-issue is not necessarily in the keylog of the "map module" itself, it could be anything stacking or downflowing or something foundational. So the personal default behaviour to have the least manifestation of this not so noticeable bug is to just re-adjust when stationary (landed, not even hover) and never change "map scale". The manifestation is more imprecision - more drift (repeatable sortie/route, noticeable relevant difference). The triggers for manifestation are re-adjustment, re-adjustment underway, change of "map scale". P.S. offtopic - about the tracks... again.. it is what it is.. so ofc we keep supplying them, which usually results is its own communication minigame of "needs track" / "track too long, create track with only bug" (???) / "track shows nothing" with inevitable certainty, especially when it comes to actual bugs, so something that is not looks, not minor, something that is functional or at worst exposes a global issue (of which there are many) or a lack of standardization and practices (which would be needed for many many things). Which has no merit except inevitably reducing contributions and the likeliness of "new" contributors. But again, you cannot change mentalities and realities, it is what it is.

well.. if you want the bug to manifest you have do do the following: MAP POWER ON: never exceed treetop level, preferably stay below treetop follow terrain ditches down to stay at low AGL and map level 0 (which is not 0 ASL but some random ASL value per map seemingly) will result in Map not moving, even with correct nose attitude and DISS-15, all other Doppler features working. If you have exceeded an undefined AGL value (I guess 40+ AGL but I was never able to systemically pinpoint and replicate, and tbh... I also did not have the time to "labtest" that) at any point, the map will work as intended (including stopping and drift if attitude too extreme, drift if airspeed-to-doppler turned on aso aso aso) even if you return below treetop. There is no reliable way to trigger a "snap"... but it has happened and can happen MAP POWER OFF: fly randomly around climb very high, really high, notice "SNAP" go down to "normal" envelope angels, notice map not moving (which is correct) change position and climb very high, notice "SNAP" which is the really weird manifestation. You also seem to have some speed and fly level at angels for some time (few minutes) for the "snap" to occur it seems. On an entirely unrelated note but topically fitting (so added as a general note of awareness for any glancers): That map corrections via the two adjustment wheels result in completely arbitrary drift that do not follow the rules of the "intended" behaviour of that functional keylog is also something that is sub-optimal P.S. But about any trackfiles.. they are currently at their most unreliable state for replicating anything on a any different system..

Well.. again thank you for pointing that out.. this is extremely relevant, especially for the glancer-in-passing and fellow product user in dire straits. So addendum ->after noticing for some time, I just tried to finally report that.. and failed to be precise beyond ambiguity again... So brace, here comes the kicker... yes, the power switch has now a different (and "better", more realistic, more fidelic) default state. Which is a good thing. Which is also a thing that should have been a thing from the start. But so would have been any sort of actual documentation (no.. neither community contributions nor marketing skids count.. they are equally dismissable, regardless of their excellent quality and positive intent [for the former]). So do your checklist and don't forget to turn your map "on"! (those of us that do not press a magic diaper button ) BUT! That bug also manifests with the map power "on" if the aiframe never goes above a as-of-yet undefined "trigger angels" after takeof AND.. and that is the real weird thing... the "snap" manifests even when the map was NEVER turned on. Sou you can trigger an instant magic GPS like "snap" with a map that is OFF and was never ON. Now how utterly weird is that? Coming to think of it, I finally made that report on a Tuesday... how.. fitting :). I would provide a lot of trackfiles.. but as of now it should have become clear to everyone (translation: cannot be longer subject to "spinning") that they do not reliably reproduce bugs, or flights correctly by technical reality and even less so in the current especially unreliable state of the track-replay system (which has been a thing for.. 1, 2 years now?). And I do not run screengrab video... and there is no function to create proper debug-logs unfortunately. I have also not made that report on a whim... I started to notice that bug before the last patch.. but seemingly only under conditons I could not systemically identify - and more often to almost permanently after the last o-b patch. With the "trigger angels snap" manfesting almost permanently more often if I keep the map off (which again.. who does that.. and our fakeflight time is or should be limited after all). So there is something going on.. and as stated not necessarily with that functional keylog... it might be a more foundational issue just bleeding through.. again.

With the recent patch DCS 2.7.14.23966 Open Beta (and maybe the one before) the Paper Map indicator for the DISS-15 has stopped working in Multiplayer while the DISS-15 itself is working reliably. The map indicator is not moving after takeoff, even with Airspeed2Doppler on (which causes drift), no movement. Any takeoff, fresh airframe, no damage, green OPER light, DISS-15 directional readout working, Doppler "Hover and Low Speed Control indicator" working correctly. If the airframe is moved above a certain "trigger" altitude at any point during a sortie, the map indicator will suddenly "snap" into the correct positon (which is technically impossible) at the time and move. If the "trigger angels" are a fixed AGL or ASL altitude is unclear at this point, especially as terrain masking seems to also influence bug manifestation. Which does not make sense in a systemic context but hints as a coincidental bug manifestation maybe related to DCS "radar" odditities overall. If the airframe is moved back into usual Crocodile angels (treetop, below treeop, terrain) at correct attitude for the DISS-15 to work, the indicator will stop moving again. The "snap" can be repeated then in a different position. This means that the module has currently lost its only means of navigation (since placeable beacons, radio truck NDBs are bugged for years by now on all available terrain modules) and the airframe has to operate in VFR, a correctly preset DISS-15 oneway Doppler and a maybe available ARK-15 beacon direction to find a FARP, a target, a destination.

Well.. I am not coming up with these labels and their actual function and functional meaning vs a direct translation. see fe ... (which btw is still not cohesively labeled between cockpit labels and keybind labels but at least coherently labeled in each) But this is what the mousemap labels for the rockers are: up - MAIN center - AUTO down- BACKUP with the earliest "official" startup "guide" video (that may or may not have seen the usual ex-post treatment by now, which I will remain unaware of) stating the center position as the correct/intended/working one from the PoV of the product. Except that this never worked.. and many-a-times back then on SRS it was very helpfull for many to solve many issues by selecting the up position ("Main") for systems to work. With the down position ("Backup") to this day completely unknown if it has a function, if that functions works, if that functions works correctly. As currently every single impact anywhere by anything causes launch capabilty and or electrical damage, every actual impact causing minor pressure or rpm loss causing inevitable crashes, and one of the many sudden FM state changes still causing the unrecoverable RBS of doom from a stable peacefull and rather leisurely paced forward transition arrest, the DISS-15 working reliably but not for the rolling paper map which has a trigger issue suddenly to not work at all and then snap around like some sort of magic insta garmin - I'd rather not dig through documentation at this point. But more importantly I cannot tell if it works now.. because the reliable marker for it (the DISS-15 map) has currently stopped working altogether (unless you decide to become a commercial airliner.. which does not go so well for a Crocodile, especially on the Cold War Server.. the actual one, not the recent social media kindergarten clone. Also I am not getting paid for this, any of this - and those that are... well. Let us leave it at that. So to conclude.. back then.. center rocker positon was supposed to be correct, yet did not result in correctly (as in "function at the time") working systems.. up position did result in correctly working systems.

first of all.. the read light going away means the gyros are "uncaged", aka working. The red light is not a "warning light", it just means that the gyros are spinning but caged. And if a button press does not uncage them... it usually means your birds systems have not enough voltage.. (usually when APU is off too early, before takeoff, throttle not at 100%, cold weather, rotor rpm too low, aso). This might also mean that the AP channels will not be able to be turned on, usually... until there is enough current in the system. For the longest time the source issue was solely that the 115V Transformer mode "auto" did not work.. and you had to switch the rockers to "main" on the left panel (breakes, not the rectifiers, the transfomers) - this seems to have been finally debugged... but I still switch them to main. null

carefull @AeriaGloria, be precise with the labels to avoid confusion (since this also is now a help-thread especially relevant for the glancer-in-passing, so we must be precise beyond ambiguity). When you refer to "yaw autopilot" you are refering to the FCS-Yaw-Dampener/assist that is the AP-"heading"-CHANNEL. Many will easily confuse that with the actual autopilot mode "Route" - the "Autopilot Course (Route) Mode (SAU-V24)" The microswitch logic will click the assist CHANNEL on and off, not bo be confused with what the "autopilot mode" does. While very convenient and less straining, resulting in a much more "smoother" flight - especially for twist stick users (of which I am one) - it also prevents "drift flight" and "crabbing", and will confine you to lower threshold limits in your maneuverability (if that it your interest). And as Aeria typed, you simply have to find out what works for you or is needed for your personal situation based on your hardware and habits. But you must understand the difference between managing the input translation of your input peripherals, your physical hardware and the in-module application of the fidelic functions. You can reach any goal you have with either but not every combination will be as fidelic and as QoL as it could be.

and thank the gods of russian proprietary product code for these (although why these are not a unfified franchise-wise global standard for all rotary modules.. or at least Eagle-modules... ) but in earnest.. despair not fellow fake digital pilot! In 85++ % of cases this setting will apply... the rest of combinations will be for A-segment peripherals, APIs, simpits.... the rest is already immersive.. aka in-module

Difficult to tell.. The topic of "input translation", aka how to configure your peripherals to hand over inputs to the fidelic functions of the module you can only test out for yourself over time. Based on your description of your hardware peripherals a "no, rudder trim on special-tab level, peripheral level might not be needed" seems likely.. but you must find that out over time. If you have such hardware the microswitch logic of "presence/absence of pedal movement" might apply too. Once you have that figured out, cast it away as a given, do not think about it for now, considerit is "locked in". Then you can focus on the fidelic functions, aka what the modules offers in behaviour and how and how much of it to use in what way for your immersive perception of fidelic "flying the Shaitan-Arba". At this point talking about your stick takes on a different meaning and is actually talking about the cyclic, your pedals are the "anti torque pedals" (lol... soviet engineering terms.. oh my...) and the throttle is now the collective. And that you have to go through - iteratively, until everything works as "it should" on a cellular level, aka for your personal situation. And that is the problem, almost everyone does not make that differentiation, cannot discern between those topics, especially when it comes to bugs and seemingly including the product provider. That is not very feasible for debugging, especially when all layers have separate and stacking bugs. And that is before the simple reality of different engineering cultures and language barriers hit. While "we" see and define "fly by wire", "dampeners", "FCS" and "autopilots" as different systems that used not to be the case in soviet engineering culture (and still is not in Russian engineering). "Autopilot" has a vastly different meaning that encompasses a wide scope of subfunctions... even down to the motorized servos hydraulic actuators manipulating the cyclic for a very mechanical linkage "trim". examples:

Because the "instant trim" is not exactly like the former "default", which was not the best solution for standard peripherals in the first place. And if you have a standard joystick and/or standard pedals (aka with springs that return the sticks and pedals to the centerpoint) you should have used "Central Position Trimmer Mode" in the first place (this is about the release point, or more precise, the point from which "new" inputs with the trims-state as "centerpoint zero" are stacked/accepted). Which - even if you had set it before- was changed to "instant" by this patch. Same as the rudder trim that was "enable rudder trim" before, it is about the details and combinations. in your case both options should be "central" - simply because it works more reliably with most peripherals. However for your PEDALS you now have a choice: You could use "disable by setting pedal axis to neutral" as the safest options to translate the fidelic function of the module to your peripheral hardware (aka input devices). OR you can use "presence/absence of pedal movement" if you fly with your pedals mostly off the center even with trimmed. The third option rarely applies statistically, but it still is a very relevant option to have for many. That is something you have to test (and weirdly enough, surely applies to some twist-stick users too). Unless you run a very complex throttle quadrant, you should also operate with everything set to one button, not different buttons for the trim... again something you have to test out for yourself (if you can retrim pedals without messing up your cyclic trim by your general input behaviour, if not, use different buttons). And check once twice thrice if you have "control helper" OFF.

This might be a source issue when it stacks with other bugs - which can result often in there being no rudder/pedal/tail effect to the left very often and the dampeners and AP channels letting you barely hold attitude and nose orientation. I was never quite sure what might cause that... but I was never looking at the pedals because I am almost always below treetop - so what an important find!!! I hope this gets the prope attention.

Also there is the battery heat switch on the right panel, which was the correct function to enable when I encountered the issue on a very cold mission map (Caucasus). At the time it felt very fidelic, and as the module is not documented (aka "early release") I was not able to judge what was actually working, what only pretended to be working and wheter it should or should not be like that (module-wise, fidelity is a different issue on top).

Well.. which is why trackfiles are not really - especially in the current state - feasible to gather logging for debugging. (trackfile was a random example - also that track spanned a long sortie with various interactions and no crashes, especially not in any trees) Again another attempt to describe the bug in plain terms but beyond ambiguity: damaged Crocodile module landed on pad (services available) engines shut off, rpm at zero engine THROTTLE at ZERO fuel valves shut pump groups turned off rotor disc brake on disc arrested (blade no longer spin) electrics shut down batteries shut down systems shut down (on top of entire electrics and batteries off) ground crew will reply with "no can do - shut down your engines" - for minutes, for tens of minutes and more. Over time (observation span 1 quarter+) bug isolated to ENGINE THROTTLE. Engine throttle (with everything else shut down, arrested, off and time passed) is not registered at zero, despite being at zero and input peripherals at zero (with no input stutter or input value detected by windows OS or peripheral software). WORKAROUND: Repeated throttling up and down (in a turned off Crocodile with arrested disc, shut engines, shut valves, shut electrics) and "request repair" until at attempt "x" of "y" ground crew will reply with "copy" (and timer later starts). With throttle workaround successfull repair starts (as intended?) with engines off, fuel valves shut, first pump group off, rotor brake on and disc arrested but all electrics, systems and batteries running. BUG MANIFESTATION: bug manifestiation in conscious observation by me 2.7.6.13133-o-b to 2.7.11.22211-o.b More detailed report and additional details as per other posts in the report. Update: new variant, potentially latent but now manifesting in over 50% of repairs in multiplayer scenarios per 2.7.11.22211-o.b -> after repair low hydraulic oil pressure warning, vanishing after startup, after takeoff random system failures, power outages and with working turbines and disc gradual loss of rotor rpm until auto-giro landing. Conscious observation only with 2.7.11.22211-o.b - no separate bug report as not enough encounters for clear manifestation pattern. Exemplary trackfiles could be provided - but see above (also again long, so only log-stamo of repair and post-repair flight relevant).

well.. and there is the reason actual bug-reports have to be extensive, and given how they are received and treated by the product provider, and under what conditions they have to be produced, less and less actual reports get gestated. That is all well meant advice - but given that I have monitored the issue since day1 of ea-release, any fidelity can be disregarded. That I never have the APU on in flight unless under very specific circumstances is a purely subjective me-issue (aka irrelevant) - but as for the actual bug, further clarification is needed. Bug was encountered and tested with - among other conditions - also: APU never running during sortie APU shut down after landing instrumentation full zero, soundboard full zero before shutdown of electrics fail-condition message present after 5-10 minutes on pad (fe while making a beverage and a sandwich) step-by-step shutdown of relevant systems, then random modules with decreasing relevance various maps and weather conditions, temperatures various damage states various pad types airfields as for any real life references, I was under the impression that my original bug-report had made clear that they are topically irrelevant as clearly none of them remotely applies. -> the reliable single reproduction is a INPUT (peripheral) engine throttle non.zero state or a failed condition despite INPUT (peripheral) engine throttle state (as monitored by 3rd party peripheral software and OS). Any fidelic considerations thus - again - can be disregarded as the bug would manifest nonetheless and also bugs have zero to do with design decisions, especially if that blatant in manifestation. So please - while constructive, productive, well intended - do not confuse the occasional glancer (the few that are left) with a topic that is - despite its suitability - unrelated to the technical actual bug.

The "Request Repair" interaction in the ground crew section of the quickcomm menu is all to often followed by a: "No can do - shut down your engine" (is it really "no can do" or is my recollection playing tricks on me" ?) -> when the engine is shut down, the fuel feed valves closed, the rotor brake on, the pump groups set to off and even the batteries and shaft generators turned off. Over time I have isolated the issue to - in most cases - the engine throttle. Explanation. I have my engine throttle on my throttle quadrants top-wheel (it is never used, except for raising it to 100 on startup, since we do not have engine degradation). Even when putting the throttle (the wheel) back on the zero-state (in my case the neutral middle position "0" of the "wheel slider) DCS does either still register an input (with both Windows and Logitech software showing a zero and no input stutter) or some other logic trigger condition is not met. That despite the engine being off, the fuel system shunted, the disc arrested and the rotor brake on and even the electrics closed down. And while this in itself is - once again - a control input bug worthy of admonishemt and attention (and will not receive the latter) this can be a real nuisance when trying to do a "repair" instead of a gamey "respawn", further degenerating the multiplayer environment. Mitigation: More reliable trigger logic, please make up your mind what the actual necessary presets are, which are entirely undocumented. While trigger checks like the rotor-brake make sense and may or may not be a boolean check, the engine throttle does not, moreso as there is a multitude of issues with input reliabily and input translation in general (see fe one variant of the pitch oscillations, various variants of trim bugs, added inputs, random control overrides, not-hardware related sudden input-stuters aso aso aso aso aso...) - so please reduce the prerequisites to the absolute safest and sensical minimum when there is no ambition to cohesively and coherently improve and go forward. Track file: https://drive.google.com/file/d/1rmY6RnfWXIMLTi7wAldJXfvGX89-Jov5/view?usp=sharing Random trackfile for random realistic bug occurence, only the last 120 seconds of trackfile need to be paid attention to, showing a random occurence. As trackfiles are completely unreliable too (for how many years now ?) I hope the issue is correctly shown when the track is reviewed on a random system. I do not run screenvideos as I have no application for them, also the "need trackfile" is the constant response and seemingly the only evidence accepted (instead of actual clientside logs, or at least a QR code based log in the track).

let the cultural de-evolution games of the process formerly known as contextuality begin, earplugs unfortunately not complimentary as screeching even under laboratory conditions in statistical significance within the datapoint-cloud most likely to be in direct reciprocality of decibel==max WHERE cognition==underage and/or intellectually minor booop!

Bug-WIPER: The wiper does not actually interact with the rain or droplet effects, there are no animations or shaders for streaks, dry streaking, spray accumulation aso. The forward shield also goes "clear" in a boolean state by trigger conditions (seemingly). That "rain droplets" are a clientside-only option and global (by sheer necessity) rain does not interact with modules is neither relevant for the bug nor fit as an explanation pretense. The same issue persists with the Mi-8 HIp module for years. Bug-WIPER-Switch: The mousmap for the wiper-switch in the cockpit covers the entire switch area, suggesting by Eagle and general DCS logic a toogle through the various settings via RMB or LMB. REALITER the actionmaps are extremely tiny for SPECIFIC swtich positions the position labels LMB-only, both breaking the logic applies in DCS in general, while being unergonmic especially if throttle-ministicks or VR solutions are used to interact with the cockpit. That in theory there is a workaround via binding is irrelevant, as this is for simpits mostly in the absence of an actual API, while a normal user will not bind this tertiary binding on the limited buttons on a a HOTAS setting. Reproduction: 100%, global, not system-dependent, no trackfile needed. Workaround: keyboard binding

yes... but if you do not follow the "correct" startup sequence or boot things up too quickly one after the after or do a one-button start this small line the wrong way round might or might not appear.. for a while (again, depending on what weapon system is selected and what is on the pylons). Again, what could anyone type... Idk if this is fidelic (aka it would happen in real life), idk if its a typo in a line, idd if this is a leftover from some iterative prototyping. I just happens.. nor not.. And as all Eagle modules are very very very Eagle.. and the early-access state (aka the actual release state peu à peu) in o-b (aka the de-facto release) tree of this module compared to the other recent module that is "different teams... do not work.. you know nothing" but also "all our ressources currently focus on..." is what it is... you stay extremely zen about it. That you have so far not seen it is actually a good sign (really) - it means you have familiarized yourself so much with the Shaitan-Arba that you being to notice details and the finer, deeper layers!

that is the range insert scale, which will go bold and have an indicator moving along for information purposes, also when auto-insert in selected. But only if the prerequesites are there: weapon system like MG pods, cannon, UB pods selected correct attidude within the limit for the radar ranger radar ranger turned on and working and electric system not damaged, electronics not damaged attidude and envelope held long enough for a solution to be displayed I reality, due to the state of the module and Eagle and DCS being in general.. well.. it is what it is.. it just is not reliably showing up even when it should. And when it does, and one knows how to interpret it, more often than not one will go "what the... that is NOT what is going on and should be displayed.. at all". So no news there or anywhere. It has been there since day 1.

for TWIST sticks

The Shaitan-Arba got "Mi8 like NVGs" a while back. "Mi8 like NVGs" == it got a keybind and a keylog that activate exactly the Hip-googles (well, goggle), in insularity, that is it, that is the entire state. The cockpit textures are not coded to interact with IR spectrum lighing state, because there is none. The goggles (well, goggle) are a superold and outdatated overlay solution, and nothing more. The cockpit itself is not IR-capable, which is correct and fidelic - but that still would result in a different view spectrum when looked at via passive IR/thermal goggles by the background light bulbs, the instrumentation lighting, and the nice (and slightly radioactive) phosporence layer on the gauges. Also if the cockpit-redlight is turned on. As it is an extremely old and outdated overlay-solution for the googles (well, goggle), none of the modules way more contemporary keylogs can properly relate and interact with the player-cam state, even if there was a systemic possibility for those to interact in the first place. Everything else is a workaround, or a fortunate coincidence, nothing more.

it is not only too twitch on TO and LDG, in general the nose is too nervous and floaty, something which has been reported many times - and got deleted with cute persitence (if only if only persistence was a thing elsewhere) most of the time, or buried as "solved" with completely unrelated contributions having zero to do with the actual topics. The wheels are not at all the physics grid handshake anchors (as with all DCS modules it seems), the AP dampener suite and manual trim keylogs seems to be fighting each other randomly, input values are stacked when applying trim, the AP channels randomly go haywire, the dampener thresholds can result in the dampener logic making you crash uncontrollably - and to each issue you will get something like "not true", "need tRRRRaKKK file", "adjust curves" from random directions. And every patch something changes for the better for other things to revert randomly or reintroduce bugs which are clearly a completel lack of repo-merge-systemics. Weight, mass, inertia seem to also randomly exist or not or get overriden or commented out by "something". During any part of any envelope you can go from being in awe how great this module is fidelity-wise to almost vomit because you are suddenly bunnyhopping around in a Fortnite noclip-cam. So just do not worry about it, there is nothing you can do - the socalled "testers" from the community (seemingly the only ones doing any actual testing) seem to be engineered to be extremely uncritical and the usual social media relevance dwellers (mostly, exceptions will always occur and be notable), some of them openly stating "I don't care.. I just wann shooooot things... uggah uggah" (or along those lines). Thus further limiting what little effort there is left to actually even contribute any bug report anywhere. Pair that with a rather "unique" product provider like Eagle, and nothing but a shrug is viable. Unlike the Apache the Hind might end up in Harrier territory when it comes to "early access", quelle surprise.

indeed, that was it.. and of course it is nowhere mentioned in the keybinds... but I seem to remember that there was a post at some time somewhere and I mentioned to change that keybind to a single bind because of it. but at least I know now the hardcoded bind again, thank you

I moved my DCS install a while ago an managed to (of course) nuke my binds. The Hind module is the only module (thus far), which uses a different keybind to access the "quickcom" menu "in flight". (which is the typical Eagle way of doing everything ever piecemeal here and there with everdifferent approaches, and never follow up on it but that is a different story) I have tormented the search function but for the love of typing... I cannot find it. It was mentioned (that is how I found out) - but I need the hive mind to help me out here, please, pretty pretty please with a cherry on top! (obviously I also have not found it in the client, cementing and extending my incompetence as a fake digital pilot to the keybind management) So again: Please, does anyone remember what the keybind is called to access the "quickcom" menu "in flight"? Thank you in advance.