rogorogo

highly likely - which would be prudent but prior observation shows that the Franchise - while certainly en route, maybe, finally - seems not far enough in franchise-wide modularity, black- and whiteboxing, global systemic functionality for that to not cause issues. too much ancient baseline functions, first core single thread code, insularity in modules and keylogs -> conflict bug potential

and no sooner than having typed this - after an evening of futility - another rebind (increment #926) of the very same controls now make it work flawlessly. Murphy's law - or codeline trolling at level 666...

noticed that too... hardcoded defaults that do not show up as line items.. probably a repo-merge-oversight or just a general time contraint issue. If only if only there was a proper bug tracker/ ticket system for module by Eagle....

as a remark - THAT sums up "a" or "the" problem - while the dampeners/trimmers are perfectly modeled fidelitywise - there is no feedback on the game input/IO translation layer. The in-module cyclic is not rendered at an offset (as would be the case in the 24P iirc), there is no feedback on the diamond in the control feedback (and I personally want to get rid of the RCtrl+Enter ASAP again not only for uncluttering). And as I/we/most of us do not know what is planned, we should maybe point that out. Also the labeling on the option to include the torque-pedal axis, the control line items for manual cyclic-trim and last but FOREMOST the 3 different TRIMMER translation IO keylogs needs to be reformulated more decisively and beyond any amgibuity. (all of the above also applying to the AI helper topic, massively - but different topic, thus would be off-topic) Which has zero to do with the Shaitan-Arba being perfect as a DCS module, its character and quirks translating nicely and the module not only already being what was expected (by me) but exceeding what (I) was hoping for. Challenging, unforgiving, rich in character, unique, keeping us involved in every little bit of the loop and the flightplan. And not at all like the Mi-8 (just the narrow frame, the winglet pylons and the narrow gear stance make sure of that ). All imho ofc. P.S. Best purchase ever! Please E-D take note, stay cohesive with the early 29, allow an early F-4 to happen (as was finally done with a mid-gen Lighting ) as a dancing partner for my supersonic traktor of the motherland. There IS a relevant market for the era.

weirdly, those do not work when bound to the same coolie-hat/pov switch as always - for me, for some... so caution advised, just try keyboard binds

^^ Personal Section (weirdly only shows up if you log-in) https://www.digitalcombatsimulator.com/en/personal/profile/?login=yes

same with a Standard X-52, any button does not bring up the menu, not "just show" or "just hide" (as weirdly it is not a toggle, not even as a keybind, although the keyboard keybind works as one). The coolie-hat input somewhat work (although there is ofc zero feedback what you are actually commanding, idek what is planned, since for some reason a one-button radial with headtracking or coolie-hat input was not desirable for Eagle itself) - but the target menu for selection fe never shows up. unrelated: gear lever, specify if you have bound/used/preset the gear lock too, the lever will move (and does so on my rockers, but if its locked-up it stays locked.. up, same for locked-down. So you have to select the target position before using the rocker or whatever is bound for the lever itself. So clarify if the problem arose despite this being applied.

I think the OP was referring both to the control input layer (heavily influenced by the 3 different trim systems available.. and they all three are different and three, not two, default behaves different from the no-spring-no-ffb one), the dampeners being set on or off and on top of that the trim system (supra module and outside the in-cockpit fidelity only arbitrarily registering inputs for some -> aka meeeeeeeeee). I thus far somewhat replicated the very same go-around with the pedals behaving differently with the very same settings and input, making my aiframe spin out of control while trying to apply some, any torque input that neither happened in-fidelity nor supra-module in the input. Odd.. shrug... but not the end of the world - we just have to find the right combination of settings for our personal peripheral situation and then trace down a potential source issue. RCtrl+Enter is a must atm imo.

tfify

may I - just for the sake of it - remind of common sense - and wiring. Demos and PR are exactly that... actual system capability is something else - or why were B-52s until very recently carrying precision munitions draggily around on external pylons with empty cavernous bomb bays... We will get to enjoy a "24 P" - which is very muched spelled differently from "35 <<enter letter here>>" The former has cabletree wiring for 4 stations with 2 channels each, the latter a cabletree on one station for module carriers up to 8 channels. Variations will see the light of day.. eventually.. for both.. or not. None of which has anything to do with the module in discussion for the foreseeable DCS future. /thread (for the DCS-module... for the topic... keep going.. for one has to have seen a 72 with Italian (sic!) upgrades to not believe anything to be possible any time.. somewhere)

all good, just asking - and this is a very prudent decision.

just a question: Is it an oversight that there are no Su-25T slots in the "Phone Booth" map mission? Someone wanted to play Phone Booth and fly one but made me aware that only Grachs are available, not Ts. If it is an era/version consideration I am sure weapon availablity could mitigate that, imho ofc.

well... first of all, you should not have ANY AV suite running when you start DCS. It does not matter how much you have whitelisted, empty out your system tray in general, nothing unecessary. DCS has ancient first core single thread code lurking around in core functions and keylogs everywhere creating bottlenecks anyway (with the client system being at almost zero load!!). Next - the issue with the serverlist will happen arbitrarily, it just has to do with how that get-request was coded (or rather, once coded as an afterthought and then never ever addressed anymore even with a single keystroke). So if one is affected by that bug - do the technocratic, the factual, the emotionless thing: Activate your base NATIVE dcs counter in stage one (via the default keyind, not alternates, since... well.. different story). and watch the MIS-timer (not the fps). Only click on "multiplayer" if the mis timer is pulsing. Then always immediately click "favorites" (also HAVE favorites), unlick , reclick - always with pauses with the active selection filter on. Until you have the servers listed you want.. stop fumbling and leave the selection on. There is not much you can do locally... it does not have a purely local source issue, not a purely infrastructure related source issue. And as there is no proper bugtracker for core DCS (by Eagle) and their reception of even simple technicalities can be... tricky.. there is no merit in going around in circles. That "the community" has been very firmly engineered (by accident more than by active compentece) into the "eyyy have no problem so u wroooongg - REEEEEEEEEEEEE" stampede is very very very detrimental on top (as is multiplayer by now being almost exclusively in o-b branch instead of stable for... "reasons"). To eliminat this issue would not be a financially relevant task in effort. One day at most to replace the proprietary ancient full request table with a contemporary lobby keylog, relable buttons and their functionality (two very different things in DCS) according to common sense. But there is no use in raising a fuss, just shrug, help each other out and wait for a trickle down, finally (whe it comes to era cohesion and suite viability it has already somewhat happened, it only took about a decade and a change in ownership ). Stay zen!

https://leatherneck-sim.mantishub.io/view.php?id=1134

btw OP: latest video clears it up - without acknowledging that the video comment scriptline was wrong (we all have vanities) - he is OPENING the valves TO SEAL the canopy. Which means the cabin is run with slight overpressure and the rubber seals in both canopies/doors are inflated to (somewhat) hermetically seal the crew compartment. And as always in life.. it was an imprecision in formulation, nothing else.

<same as in "general"> and/or in-module doublebinding

see - in the end YOU are the person with more information to chime in... and thus we are back that maybe everything is in order... all follows common sense and logic and it was just a double lapsus in commentary probably caused by an internal miscommunication

picture label in OP of this thread: inscription <- Закр / откр -> mounted BELOW the valve-wheel, inscription arrow left "close", arrow right "open" --> counterclockwise turn means "opening valves" demo module label in Wags-Video: inscription <-open / close -> mounted ABOVE the valve-wheel, inscription arrow left "open", arrow right "close" --> counterclockwise turn means "opening valves" from youtube: huh?... well... soviet era tech can be strange... but if that is how it works.. that is how it is... assumption: sooo - again in the absence of having done any proper research - "most likely" .. the animation RESULT of the valve-wheel turning counterclockwise got reversed / is reversed by a line-type/repo-merge whatever... (normally if you want to "close" something with a wheel, you do clockwise turns, like screwing in a screw... truly globally). Why this assumption? because the picture is from a real life airframe, and aligns with what the demo-module label depicts. But I have drifted enough into unsubstantiated theorycrafting already (in the absence of having quick-enough access to proper primary sources), I was just following basic logic or commons sense, so it will be resolved in time, or someone with more information can chime in... or someone happens to know how it works... or... you have to actually... or... two weeks.

caveat: this label as shown in the picture is mounted BELOW the valve-wheel. In the module demo the lable is mounted ABOVE the valve-wheel. by this logic a clockwise turn would close the valves, and a counterclockwise turn would open them. And while in the video at timestamp 2:58+ the line "next... ... and close those" was dropped, while making a counterclockwise turn of the valve-wheel. Also opening the valve as both labels would indicate. The hind is flown with constant cabin overpressure (slight), not for altitude but for ABC (well BC) - protection of the crew. And normally (carefull... not based on proper research of actual manuals or anything for this airframe and system, so someone qualified might and should expose this as bollocks) cabin pressure pneumatic valves are opened once the airframe-system is booted and running, and thus the pneumatic valves are operated by the proper module (solenoids with a relais-governor most likely). So.. that may have just been a lapsus in doing the live commentary in and for video.. or maybe the just the mousecatcher mouse-over label was wrong... or I am wrong.. or there was a typo in the script.... or the rapture is about to happen... TWO WEEKS!

Ahem... that was exactly what I typed, unless the nuance and the use of quotation marks evaded you. I am very much aware of the original design outline, later realities and - as I typed - the extent of application in the originally intended purpose. But - unrelated - being an integrated squad with its own support (literally as the "BMP" methapor implies) is different from the definition of "a" or any form of "troop transport". But apart from that, it is futile to attempt to discuss either of the two topics in an exchange in a DCS forum, there is extensive factual information about it readily available. For those in error a simple pointing out, a hint where to look and/or what to look out for suffices. Which is what I did.

it's there are standards to be upheld if memes are to be applied

iirc, if the "civilian traffic" setting is turned completly down/off in a/any participating client, the trains will not show up for those clients, even if deliberately populated. They are environmental scenery objects after all, not mission objects part of an asset pack. But please treat this with caution, idek if you populate a track or actually place the object - I just wanted to help with information that lingered in the background of my distracted grey matter, for those that might glance at this (not for the OP, who by now hopefully knows... many years later )

out of earnest interest - what made you have that impression? The Shaitan-Arba/Glass/Crocodile/Hind - P uses a SACLOS system, the sight operated by the pilot-operator is gyrohydraulically stabilized against vibration but not even independently stablized, it also has a 2 stage stepladder launch authority with weapon release by the pilot-commander. The only way I could think (aka suspect without proper research) of "guiding" two projectiles at the same time would be to get one on a - stationary - target and then launching another one, effectively releasing the first into unguided trajectory while guiding the second one actively on its target. Moreso since they use a wireless system (no guidance wire break risk but also jamming and frequency concerns if more than one projectile en route). And again - those are SACLOS munitions, they have no independent behaviour pattern or target aquisition/designated target auto-slew, just direct optical guidance of the projectile onto target by a pilot-operator (yes I know that crew designation reads weird but that is the English translation, so someone speaking Russian as a native tongue should educate us if those station designations sound odd in Russian too). PS: to avoid confusion - "direct guidance" in the SACLOS version of direct guidance, not direct projectile steering as in MCLOS

@Alpenwolf just an FYI about a potential typo (or a global 2,7 bug, in the latter case disregard). In the "Phone Booth" mission I was flying around recently (iirc last weekend so around a week ago) via RSBN-Navigation in my 21 and noticed the following weird behaviour. The RSBN global DCS channel setting for: Mozodok (ch 9) sent me to Nalchik Beslan (ch 10) sent me to Mozdok Nalchik (ch 8 ) sent me off to somewhere too but I have not tested where As these are the global DCS fixed channel settings for the Caucasus map and I found nothing in the briefing or in the F10-map airfield info to indicate that these were switched IDK if that was a 2,7 related bug, they were switched on purpose (if that is even possible for those and not just the unassigned one as it is in ARC), or I have had #justaDCSmoment. Since I even touched down in Nalchik (only running over 1 poor infantry guy on the strip) I also noticed the airfield is offering all services even directly on the runway. I also do no know if you intend for Beslans's RSBN to be even active as long as it is in contested state. So maybe you should just be aware if that is a typo-related bug - if all is in order or a global thing beyond your influence, please disregard.

I was not qualifying or judging or expressing preference, I was merely pointing out an observation. Which applies to the 21er, the 29, a Hip, a Kamaz truck, a Moskvich too, anything if surplanted pop-culturally by spraypaint. And - unrelated to the observational phenomenon - personal preferences in DCS are often catered too by an abundance of available liveries and free choice of BORT numbering. Which is mostly feasible as even the involved scenarios are very AWACS, BVR and IFF at least in ID and merge. As for the gear, well.. random background footage in secondary applicant territory and lower-echelon units do show the inevitable - when you do not have the resources to constantly maintain, service, replace, pamper hydraulics.... but that applies globally, literally globally.