rogorogo

Thank you for the fix, the QFE bug was really hampering NAV usage for proper Viggen procedures.. May I ask a question - out of sheer interest, nothing else? Eagle now has been for a while encouraging mods to use the "saved games" folderstructure in the user profile (for QoL ease of maintenance and to not interfere with core DCS files or changes to them). And to use <drive lettering>:\Users\<profilename>\Saved Games\DCS\... seems to work very well. But you prefer to keep all of your mods in the core DCS folder structure <drive lettering>:\Program Files\Eagle Dynamics\DCS World\... Is there a specific reason for that, a technical one (fe OvGME settings consensus) or is this just a personal preference or habit? Again, asking just out of interest, nothing more.

RED FARP, unguided Rockets, bombs, fueltanks, cannon pods, yes, all AAM and ATGM no

the integrated VOIP radio patch is here, gentlemen

well.. from the document they have made public... it basically IS SRS with a lobby added (akin to the faction rooms or global lobby that SRS has too). It dynamically switches to Radio (overlay) and in-cockpit radio functionality (ff modules) once in the cockpit, while immersion and fidelity-wise the (faction) lobbies could be seen as the "briefing rooms" when... well.. being ded (and the clone vats gestate your latest digital Gestaltwesen). And the less external software, the less scripts, the more native functionality - the better! For an ABUNDANCE of reasons - most of which would go wayyyyyyyyyyyyyyyyyy over everyone's beautifull scalp. And yes.. bless him.. and THANK YOU to him as well (and he has not been treated fairly.. but.. different story). And if we all take our vitamins and consider cryogenics we might see a teamscreen that does not show everyone's aiframe and a role select screen that does not show everyone's homeplate and aiframe all the time for everyone. And an "x" on markers that closes them, not delete them, and actual tactical markers. That is surely on their roadmap - next to world peace. Both have the same existence probability. 4-1-2042, earliest...

It is not, it is just completely superfluous information and IMMENSELY clogs up visibility - the simple crosshair without anything else is just so much more simple and QoL (caveat: it seems you lose the "status" coloring... but honestly... everyone flying on your server has the spatial awareness to either know the status automatically or quickly glance at the top right corner. Actually - in case this has to been typed in a while - we should all constantly say "AND THANK YOU FOR THAT" exactly because of that. This product is called "Digital Combat SIMULATOR" - not "Fortnite Pew Pew" - and despite the product provider throwing nothing but obstacles into the way of server-runners, this server, your server allows the full visceral experience. And the loop includes the "workload" of looking out the window, using TACAN, RSBN, ARC, encourage teamwork, SRS usage... and not just ripple-spamming 65 trillion in munitions to get 3 airkills (2 of them friendly) and then RTB for an insta-respawn. So, again - THANK YOU!!! Btw... a question: Any plans how to test/what to do with the upcoming integrated proprietary radio solutions by Eagle (it just took them 15 years to decide and 2 years to make). While I would very much like to watch Ciribob shake his head at a frequency of about 26k per second (for good reasons and with the most outright of rights) - it is what it is, for better or worse. It could bring more players on in-mission global coms... but from my... irrelevant and outside point of view a decision to use only single system would need to be taken.

your are not flying "every other DCS helicopter module" - this module has a unique flight envelope and also, unlike "every other DCS helicopter module" an integrated "autopilotky" that at its most basic has input dampener channels. If you cannot follow that you might want to educate yourself about it. The part about how it works in the end for us, on the peripheral side was pretty clear though, or so I thought. Because - thankfully - this rotary works entirely different to any other rotary. Rudder trim for twist sticks worked from day 1 of early access. The need for further attention has nothing to do with the concept but the implementation.

Just FYI - as many others I use a twist stick, I have "control helper" NOT enabled (and you should very much stay away from that) and only the "include rudder" (== tail rotor/yaw) option enable in the "special tab" and the choice of "central position" trim mode for the joystick. And usign the "trim button" for the "autotrim" works perfectly for the "rudder", with ONLY the "pitch" and "roll" dampener channels of the ВУАП-1 system enabled, NOT the YAW dampener channel (that will already cause issues or at least make any corections sluggish or cause overtrimming) - until it does not. Which has been bugreported. Sometimes the button just done accept any trim, sometimes it results in a trimlock but the coolie-hat manual trim still works. Especially fun when both happens in a reversed sequence and then you have to try land the Crocodile from a neutral trim reset cylic center (which in itself... but that is a different story) It is not a problem of pedals or a twist-axis, it is a coding issue. It should also not be "like in the Mi-8". The NATO label for the Mi-24 is "Hind", not "Hip" and when it works, it works very well and is very fidelic. Imho ofc. But there are issues - and not only there - that need to be resolved - but that mean earnestly looking at them, not doing adaptions of Ian Bainks novels.

I did not to be honest - but I also focused more on the lack of noticeable effect as described - I was basically flying around for 2 months with the valve closed,,, both SP and MP in all situation under my control and completely out of my control to have a wide scope of scenarios and datapoints. But it sure would be interesting - it is also true that under normal envelopes it would not be noticeable. But we tend to fly in extreme combat turns... and there was a reasons that crossfeed valve was put there and only there for those two tanks. Maybe someone finds the energy to fly this in a replicable scenario with just one pump running and the crossfeed OFF to see what happens and if anything noticeable happens.

Well, for the reasons I stated in my original post. But again, compared to other issues this is neither a big deal nor a priority. There are other things that would need attention - and not just for niche fidelity interest percentiles but all purchases segments. We shall see - or not. Either way those that are attentive should not cease to provide information, no matter how it is treated. Because - and that is part of the overall systemic issue - this is literally a standalone product. There is nothing like it, it is a de-facto monopolist product and product provider.

definitely, and it seems some more attention should be paid to the illumination there. not only the label lamp itself is missing, which is very much a backlit label but curently also the NIGHTfilters (basically deep red plastic that is relatively thick to eat lumen are better visible at daylight than the actual dayfilters (translucent plastic not eating lumen of the bulbs).

if you are refering to this schematic: then yes, it does. but as you can see here (yes I know thats a D and a 35 export and some others, not a P) the entire airframe, not just the powertrain is tilted to optmize certain envelopes (which it does very well). The Shaitan-Arba basically always "hangs" under its powertrain, that is what you actually fly, the airframe is just tagging along (at various angles at various stages). And nlike pop-up focused rotaries (where the powertrain is engineered to supplement the aiframe orientation as a primary design focus for the attack profile) the Hind is the only aussault-rotary ever built. So the lower tanks, if out of balance should have a noticeable effect when changing envelope. Just an effect, nothing that cannot be countered by trimming or just adjusting the cyclic but an effect - like the collective has noticeable effects on the airframe in all 3 relevant dimensions (yaw, pitch, roll) in hover-state (apart from angels ofc). But again, if that is not modelled, not a problem for anyone - there are only a few that will even notice or care. These days DCS has "players" mostly, not "flight-simmers" (that is not meant derogatory) - they do not primarily care about the fidelity of a full fidelity module, they will adapt to whatever behaviour it has. So if Eagle has not yet found the time or has not plans to somewhat include that in their tables (and some things are very much table based, see VRS in different states or the noticeable VRS warnings in different states or RBS behaviour in different envelopes) - this is a non-issue. If it is an oversight or something not working as intended, I have tried to bring attention to it, not more. And I did not have the time to find proper sources, so my response was on google-level. But then, I also do not get paid for this.. and any time invested might suddenly fall victim to a black hole excession event without Ian Banks stopping by.

Just out of interest.. would it not again - and not solely because of the LotATC issue - be feasible to virtualize the node (if something like VMS is available) and reset the entire server via script for a map mission change? This would ease maintenance a lot and normally results in a performance gain from the 20 years I had experiences singled and clustered arrays, down to the point where I virtualized even single boxes not standing around in a datacenter but at random infrastructure points. Also the cycling tended to be insanely quick. This would not only make LotATC available independently from a proprietary solution being found but also reset all connections, clear all caches and generally increase performance threshold for every mission, especially when the map is changed. Most of all since any exception catcher triggered in a prior mission would be reset just by the services being completely restarted.

again.. of course you can.. but as I tried to explain earlier.. an unlucky few (to some point also me) get hit by state-bugs.. which for them has the option to make a landing take 4-6 times longer to establish a perfect hover in trim state, then never be allowed to go beyond -1,5 on the VSI... ..or risk random events like a perfect soft landing.. just to blow up nonetheless, or shut down the engine and the tail breaks off (no damage state) and just weird things. This is bugrelated, all of it reported, some of it even acknowleded, at some point in time it will not be an issue. And those who are not affected by this have an entirely different experience (things working as intended). But for those affected even a supercontrolled crab can mean doom. For those even rolling on terrain is not an option - because it will result in the same events. That is why a rolling landing on a suitable surface within the services radii can just help to bring return touchdowns back into combat landing time for now.

noticeable change of CoG with unequal drain, or fuel starvation in a negative G maneuver if still only draining from a low state tank, or oscillation if one tank is still full while a drained tank is sloshing But again, this is not an end-of-the-world bug. If its not modelled and just a rocker-animation it has zero effect on the module being enjoyable. If it is modelled, then something is not yet where it is intended to be.

but so it also did before the LotATC testing here and there. If the server is a virtual node, would it not be (for many reasons) feasible to just have a restart script for the whole node? Of course this only is feasible for a virtual node, not for actual physical hardware (aka only if the server is virtualized even when running on an actual single box/pc/server on its own, not in a cluster)

I'd like to second that. For clarification. The module still has several ... "odd" issues. Fe a trimlock bug fo many people, or a necessity to trim-reset to have stick input.. or input lags that are not actually lags. Thus sometimes people have to transition into a hover, trim perfectly for that hover.. and only then they can land on a pad. Not only because the module decides to "flip" behaviour stated once the doppler comes on.. but also you can repeat a landing under the same conditions with "holding cyclic only" vs "holding cycling from trim center pos state" and have a soft landing (latter case) or explode for no reason (former case). And that is before you raise your eyebrow to suddenly different VSI indications, actual behaviour of the airframe and different threshold between the two scnearios mentioned. Again - unbeknownst to most and most will manage because they just "play" and will do what is necessary, they do not really know about or look at the fidelity gradient of the module. Esp in heavy conditions that can be very odd... especially when you can also encounter random bulding up oscillations with zero inputs on the cyclic or collective. Of course all of this has been reported properly by a few people here and there.. but this is not very on-the-nose.. and Eagle is.. well.. Eagle. Let us leave it at that. Thus sometimes a rolling start is quite a resolve for some (or if you want to do the "Afghan nosewheel" on Persian Gulf or Syria). As much as people affected by this bug - and those are unbeknownst to most - should sometimes divert to an airfield instead of a FARP/FOB on the return leg. Example: Flaps 1-3 randomly crashed while we were just flying on PG in a random plain because he had a trimlock (that bug result in no inputs from the cyclic but only the coolie hat until you press trim reset).

Part of the startup procedure is to sett the "fuel delimiter valve" rocker into the upward position (on/open). I have flown the module in SP and MP now since early release and having this valve either OPEN or CLOSED has had zero effect on the module behaviour and consequence states. Not in excess maneuvers, not in limit maneuvers, not in positive or negative g's, not in damage states, not in anything noticeable where it should result in a different turbine behaviour (to the point of fault). So it this actually background modelled in any way or is this (as of yet) just an animated rocker in the cockpit render? Which is not a problem either way, just some clarification would be helpfull. There is also no need for a trackfile, since you cannot "manufacture" a few small ones for the variety of testing scenarios, maneuvers and states applied. Furthermore since there is a noticeable difference in many things between SP and MP with the module, which can be a little bit confusing sometimes.

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

oh all deities of Russian netcode and whatever I need to blood sacrifice too - hopefully not too long. for some of us "casuals" - this fidelic era scenario provided by a community member for random DCS players like me is the only and sole place we can go to, despite our, or at least my "questionable" competence. It is also the only place that makes some of us willfully and selectively ignore most aspects of the commercial product provider and the products decade old problems, like a beacon of naive hope or something .

sidenote: also because this is the "Cold War Server" - so the pylon limitation for the Viggen, especially if done for fuselage pylons for the RB-24 for represents the AJ-37 Viggen of the Cold War. The AJS-37 Viggen was a livecycle iteration done after the Cold War more or less representing a "super" model - and we only have AJ(S) variants, otherwise we would have the 30mm in the nose of the Fighter Variants (JA-37) available. But they are an entirely different airframe, they just look the same. So again, this is feasible, as it is to have EARLY 29's (A) and F-14s, moreso since we can still hope that next to the EE-Lightning, and maybe one day finally an F-4 that can be made suitable that the full fidelity 29 might be an "A" instead of a "C"(S). As for the rest.. I am sometimes inclined to shake my head about how persistently people want to ignore the obvious. The "why" of certain plattforms being used wrong is down to people and the likeliness of their preferences. Where they "come from", where they "go to", what they "think" (or not think rather). Catering to that in any way shape or form will achieve nothing while eroding the experience environment of the playfield for everyone else. That would be a mistake, not because I think that (no one cares what I think and no one should) but because that is simply how things are. Not good or bad, not black or white, just "are" by factual discovery. Unless popularity, or populism rather is what is to be solely cared about - but then one would have to run honed social media channels catering to the lowest denominator, have a "posse" of fake-friendly fake-concerned guerilla seed proxies and message spin surrogates. All to seek - as an adult of voting age - the adorment of ones ego by the underage and the intellectually minor. Which - unless I am severly mistaken - seems not to be the case. But should be an admonishment to some of the populace acting willfully, wantingly, selectively ignorant elsewhere achieving nothing but validation of mechanics applied ever since the dawn of time, just in contemporary media tools.

well.. as an occasional participant of... questionable.... competence taking advantage of this server I am the last person that should type suggestions... BUT.. I am Austrian and we can not not have an opinion on anything (see.. that is what you get when you take our toy-empire of KaKanien away instead of letting us ruin it and ourselves ). Thus typed... Given what knowledge of the engine, the product and the entire suite I have for the moment I think the serverrrunner is absolutely right with his hesistance to use more AI. It is a matter of performance. Bombers on the other hand seem to have the least impact and work somewhat reliably lately from what I gather. So would an inclusion of bomber flights (more than 1 airframe) on and for BOTH SIDES (for clarity, so both B-52 flights AND Tu-142/Tu-22 flights with maybe suitable AI escorts of airframe types we normally do not get to see )in the mission, and a dynamic situational trigger as outlined by Apok be an easier to reach goal? Moreso since it would also have the addidional impact of adding/enhancing gameplay loops (no matter which population numbers and in what dissemination are on the map): Interceptors like the Mig-21 can actually intercept (with GCI if Magic is online) multirole fighters like the F-5 can enjoy escort duties (with GCI if Merlin is online) Everyone may see some as of yet omitted modules (of F-4, why Eagle, why.. smh) at least as AI (used as escort and AI CAS) it helps break up a little the dogma of pure "tactial" fixed wing operation (CAS, Anti-CAS, lookdown) for higher angels AO variety Some weapons that do not work reliably tho this day (yet, we hope, see R27 standards for all modules instead of per module, see AIM9 standards) could see more use (fe R3R) in mixed loadouts fe Bombers should do some actual damage on actual targets, making them not scenery but something that has to be considered and reacted to I am also stressing the bomber issue as the upcoming EE Lightning (whenever and if that module sees the light of day) will be a mid/latecycle bigbell(y) version perfectly fitting the era and giving Blue also a pure interceptor, and the 21 an almost perfect mirror airframe (as it is duly missing an early F-4 variant as a FF module dancing partner since the dark ages, but a mid to late lighting is actually an even better fit, really). Thus both sides would have actual interceptor loops available, not only against AI bombers but also against fighters -> PvA. But, as typed before, if it can be made to work, of course small flights of small fixed-wings would be nice, too. As for "statistics", as typed by someone else. From my PoV I can understand where this is coming from - but I would like to utter a word of caution. While it seems logical and common sense, it would mean a lot of effort (aka a website) and it would also inevitably have unintenden byproducts this server and this server-population would like to and should avoid at all cost. Of which the "cult of the liederbored" (not a typo ) would be the least of the issues (let us leave it at that). A simple serverwebsite showing the current mission, map and briefing dynamically on the other hand and "maybe" extremely carefully chosen and curated considerate statistics naturally would go a long way to enhance the experience. But again - this is just an observation, another angle for consideration - all of it and just that.

Was the mystery of the abduction of Blue 4 by aliens in the beginning ever brought to closure ? I SAR-patterned its location are 6+times and I had seen it before in a Mig-21 in an earlier mission - but all I was presented with... was sand, sand, and more sand, and villages with supermarket parking lots. No EWR group, no dispersed AA, nothing but sand and sandy beaches... And we know the aliens gave us Blue 4 back since it got destroyed later... but still.. just odd. Moreso since I would normally blame my client and my - far beyond geriatric - system but all other assets were present all the time. And yes, CA is a very relevant addition to the experience, by mitigation of long omissions by the product provider alone but also by just adding a human element and unpredictability to ground assets (positioning, application, mobility, intentions, changing plans, reactive and proactive everything).

may I ask - no one in particular - how the EWR map mission ended yesterday? I felt disappointment that I had to leave right when it got really interesting, and the swarms of SRAA-HMMVs & Bradleys were starting to move under JTAC supervision in overlapping groups. I feel like I missed the best part, since it meant dangers & surprises and challenging ground units beyond the obvious anytime and anywhere to encounter. Also - just a sight to behold. The dust-columns alone

again a very thought through concept and an iterative approach - for a Cold War setting on top! Also a surprising performance to this point for the population ratio of the conflict zone. But a question remains: Why the magic GPS marker? avigation via TACAN, ARC, RSBN, terrestrial is an important part of the gameplay and interaction loop that also contributes to pacing and character of PvA interactions and players themselves. It also - longterm - defines the likeliness of SRS teamwork and GCI interaction (Overlord or human). The magic self-omniscient GPS marker on the F-10 map thus seems like an odd concept fissure.. even somewhat detracting or dragging the experience seemingly sought off in the wrong direction a little bit. Unless this is a conscious choice for popularity, which is absolutely viable and feasible - but a little off-pitch with the experience-outline.

funnily enough I immediately noticed this bug AS A DEFINITE BUG on my very first glance at the Viggen module. It may or may not also be peripheral related, for example "some" coolie hats on "some" peripherals or "some" axis translators on "some" peripherals may actually be able to successfully bind and translated the INTENDED diagonal input (clarification: comment restricted to the peripheral input, not actual function of the actual stick and its digital representation). That even the working "axis' " seem to be boolean even when bound to a granular control peripheral and/or axis makes it just even stranger. Alternatively, this is some arbitrary typo bug that just has not gained enough traction, is not "on the nose" enough to be a priority or even noticed... thus it lingers on... for 4+ years.... and not even a commenting out of the cul-de-sac binding item line ( 4x " // " which takes about... 28 seconds?) as a mitigation surfaced.