zerO_crash

@Vibora Just curious, and asking this without any commitments being made: would a French F1C be of interest for you, even as a separate purchase from the Spanish F1s? The Spanish F1s are fantastic, adding original French ones would open a whole new spectrum of missions and scenarios for this fantastic aircraft.

Good, then we have the issue settled. The keybindings are lacking in a good couple of cases, but they will come. Don't worry. One simply has to be patient, as with such advanced modules, the development time is counted in years. Still though, with such a basic feature, I'm sure it'll be updated in not too long

It occurs to me that you have absolutely no idea what you're talking about! It's clear to me, that you don't get what you are doing during the startup, and actual flight of the helicopter! When the gyro's get warmed up, and you cage them, after running for 1-2 minutes +, - that's is only the startup procedure. The switch for changing which gyro to use as primary, in other words which gyro is supposed to be feeding information to the PKP-72M flight director, is used outside of the inital startup. While the ED manual is practically non-existent at the moment (public release), the real world manuals specify this more than enough! Part of the main procedure, post start-up, is to check the SAU-V24-1 automatic flight control system, and that is perfectly described in e.g. the manual of Mi-35P available online (I won't post Russian Mi-24 manuals, as I doubt you speak it.). Check the attachment! Also, with regards to the main issue. You have a problem with semantics. I will repeat again, we DO NOT HAVE any keybindings for the cage BUTTONS. All the three keybindings related to that panel, are two different ways to configure the SWITCH. Again, THERE ARE NO KEYBINDINGS AVAILABLE FOR CAGE BUTTONS. We are going in circles now, trying to convey this the third time. You can only use the mouse for pressing them, and that is known. Many other keybindings are missing, becuase the module is in early release. Rest assured, they will come.

In that case, it also works as it should. You are seeing three keybindings, all related to the "switch" in the middile, NOT the "buttons" on the sides. The three keybindings, as mentioned earlier, are as follows: - "VERT GYROS SWITCH - Toggle 1/2 - "VERT GYROS SWITCH 1" - "VERT GYROS SWITCH 2" All three bindings work on the "switch", NOT the "buttons". The reason there are three, is for convenience for the user. The first keybinding, let's you operate the switch with one button, altering (changing) between position 1 (left), and position 2 (right). The last two functions, allow you to bind individual two buttons that DON'T toggle (alter), they only move the switch to that one respective (specific) position. I am afraid that the confusion is from you not understanding the word "toggle" (alter). Also, since the module is work-in-progress (it is not fully developed yet), there are currently (right now) no keybindings for both "cage" buttons. Again, the confusion comes from language, I am afraid.

It's difficult to understand what you are trying to convey, mate. As mentioned before, and as per manual, the way it works is the following: The individual push-buttons 1 & 2 are for caging the respective vertical gyros. Push-button 1 cages vertical gyro #1, push-button 2 cages vertical gyro #2. The switch in the middle, simply choses which vertical gyro is being used as a source for the main horizon instrument. It has nothing to do with "selecting" what the push-buttons work on, if that is what you mean...

I see, well, then I guess the good news is that it ain't something inherently native to the Ah-64, but rather the module awaiting refinements. I'm sure they'll get it settled then. That's even more reason not to build too many habits with the current FM, and rather treat it as is. Good that we got it settled

I see. Would you state then that the horizontal "swaying" one experiences when at speed and trimmed ball centered primarily, is simply WIP right now? That you don't experience this, whether adverse meteorological conditions or not? I understand it such that SCAS is currently the main culprit to a few other, rather odd, behaviours.

Definitely, ED should have the R-60 (non-M) modrlled with updated algorythms, and implemented for the Mi-24P. There is a solid chance R-60 could be updated along with the making of DCS Mig-29.

First and foremost, throw away the notion of comparing completely different helicopters with each othet. They all resemble helicopters (co-axial/main-tail rotor, general layout, and that's about it). There is absolutely no argument to be made in favour of one or the other, based on flawed observations and comparisons. Also, "technically", Ka-50 is far more advanced than either Mi-24P and Ah-64D. Mi-24P is as technically advanced as the Ah-64D. "Technologically" however, the AH-64 stresses a digital suite, which gives it certain edges, that while lacking others of Ka-50 and Mi-24P. These helicopters are not even built for the same missions (they share some), thus again, irrelevant comparison across. While Ah-64D is relatively early in its development (so is Mi-24P), certain aspects of flying it are different, and will be different. This helicopter has less yaw-stabilization for a multiple of reasons; a) Aerodynamically, it's is not as astreamlined as either of the Russian helicopters. It's fuselage is relatively short and bulky, vs width. Mind you, that is mainly the reason why it feels more responsive at maneuvering vs. Mi-24P. I won't compare Ka-50 for obvious reasons - a co-axial rotor is a completely different piece of technology which is simply far more effective and capable at what it does. b) Its tail fin simply does not produce enough directional stability. A Mi-24P is ingerently more stable at speed due to the fact that fuselage tilts with regards to the main rotor, the fuselage is relatively slim for being so long, tail fin stabilizes the helicopter well directionally, the wings produce additional delay in rolling-moment, thus stabilizing the airframe further (tips of the wings are further vertically stabilized). As an example, the Ka-50, has three vertical stabilizers, one fin at the rear, and two on the rear horizontal stabs. That, in combination with a self-balancing contra-moment from the main co-axial further works in favour of the helicopter. Finally, the weight. The Russian helicopters, are simply far heavier than a Ah-64D would ever be, and that makes a huge difference with regards to the handling qualities. Just as a Sa-342 will feel jerky to a UH-1H, so will the Ah-64D be more potent to atmospheric effects (wind, turbulence, pressure, etc...) than a heavier airframe. c) The design of the controls, and the built in augentation. Ka-50, again, UFO in many ways. It has a state-of-the-art stabilization suite with complete autopilot functions. Never heard of any other military helicopter have that. Mi-24P, has very effective stabilization modes, one being "heading hold" which is rock solid. The mission dictates the performance needed. Again Ah-64D has its strengths and weaknesses. You cannot possibly go into this airframe assuming you'll find something similar to a different one, even if it's from the same manufacturer. There will be nuances, it will be tailored to its own mission. The reality has it, that Ah-64D has a very delicate control system, which you must handle with care. Micro-corrections are all it takes, to take handle this helicopter. The helicopter can be twitchy in certain conditions, that's why practice makes master. Do yourself the favour of having a completely open mind for a new helicopter. Also, due to the relatively light design of this airframe, it will react to wind. To top that off, the WIP-status means that everything is subject to change. You knew that when you purchased this module. That's what one signs up for, when buying into early access. Also, to the keyboard-warriors here claiming that it should take "two weeks" to solve the problem; create your own simulation and show what you're worth! End of discussion!

You are not reading thoroughly! The operational limit is 9G, however it's not recommended as a sustained (again, has nothing to do with what the airframe sustains, only a recommendation as to extending airframe service life) G-load. This is further confirmed by the statement in the manual that claims the following; "at V > M0.85, the maximum sustained G-load ("Pu") is 8G, but should not exceed 9G." Everything is correct in DCS, and in accordance with real life operating procedures. What you have to understand, is that G-load is not a static number per se. Depending on the aircraft, aircraft weight, speed, altitude, etc... the conditions will dictate what you can pull in G. The eastern crowd was introduced to this (those that didn't know) much earlier, nowadays however, the western crowd finds out about this dynamic with e.g. F-15E. Yes, if you pull more than 7.5G with a heavy loaded F-15E, you will bend the wings irreversibly. Yes, if you exceed 9G for longer than an instant with the A-A configuration (light), the wings will also start to bend beyond shape and format. Now, you have to finally respect factors like: speed, altitude, pressure, aircraft weight, and more... As to Hornet, there is a distinction between "soft limit" and "hard limit" of stick travel. I explained you this before; the F-18 is built as a 9G fighter aircraft (Finland has F-18s that are not carrier-operated - they are rated at 9G max.). However, since the USN F-18 are already operating in a highly unfavourable environment (salt is reducing service life of quipment at accelerated rate as well as carrier-deck landings), in order to mitigate the issue of shorter airframe life, the operational G-load was reduced to 7.5G (it's not 7.3G as you stated). Now, operational means - everyday use under normal circumstances. If a pilot should end up in an emergency, or actual combat (not training) and need the extra G, he can push the stick past the soft limit (you have to activate a lever on the stick first) and to the hard limit. That will allow to yield more than 7.5G, and potentially 9G or even more, at your own caution. Now, IRL, if you'd done that, the mechanics would know, and you would have to answer why a national asset was stressed beyond the "standard" envelope to the CO/XO. Depending on the explanation, you might have been reprimanded or not. In DCS, this is something that I imagine gets abused online, because people have little dignity in their flying, and take DCS with varying levels of professionalism and investment. DCS as a simulator allows you to train military aviator proficiency, but it also allows to goof around. I am personally an ultra-purist, and e.g. few servers come even close to replicating actual environments. Also, how you fly, is something that you should monitor, not a "bar" or "level" showing use/misuse. You know when you exceed limitations, and when you don't. Even if you join the supposedly "pure simulator" servers, you will see people sometimes flying recklessly and as if respawn is faster to the AO, than flying back and rearming. How many people do you think plan their route properly, do fuel calculation and ordnance planning before taking off? Granted, there is much missing (e.g. the whole intel section of actual planning), but then you have to adapt. Still, people join and take off in less than 10 minutes. Do you really wonder why they get shot down? I won't even mention what I hear and imagine is blue-blue on quake servers... Another example; IRL, a multirole airframe is meant so that multiple services and squadrons, focusing on different missions (CAP, CAS, SEAD, etc...), can use the same aircraft, which is economically lucrative for the whole branch. In DCS, as realistic as it allows you to be, an average server is filled with people outfitting their F-18 with AIM-9X/AMRAAMS, GBU12/39s and AGM-88 at the same time. Essentially flying a AC-130 trying to win the war alone. My point is, let them enjoy theirs, but if you struggle with finding good servers, then either you are not looking well enough, or you might be bound to singleplayer scenarios (there are a few decent servers out there though). Let's stick to topic though.

Yeah, that is only partial understanding, in Russian Air Forces, it's called "operational overload". Again, refer to my previous comment. The whole chapter has information on intricacies of flight and design. Page 9 of the Su-27SK manual confirmes Su-27SK being 9G capable. The constant 8G is again, due to extending the service life of the airframe as much as possibly doable. My former comment explains this. What ought to be said, is that much depends on weight (mostly due to fuel load). Su-27 has no external tanks, because it's a design that essentially is a jack of all trades. If you go to combat, you practically never carry more than 50% fuel internal, often less. Anything above that, is either a carefully tailored mission with on-station time or long initial/final flight, or ferry. It's not a configuration that stresses performance.

I was AFK when writing back. That's what I had noticed! Exactly, Vikhr-M is again the complex denoted by "K" in the GRAU-index (9K121). The missile itself, is the (9M-127-1). The "...-1" is the variant of that specific model of the missile. As I am looking at now in DCS, that is exactly what I looked for. Good job Flappie! In other words, remove the "Vikhr-M" from the name of the armament, and it'll be correct! Either that, or if you want to keep the callsign for the missile, than change out "Vikhr-M" with "Vikhr-1", as you indicated in the attached images. Both solutions work. Splendid!

I was considering that, and whilst with a bit of training, one should be able to place the marker with a relative accuracy, at the end, the further the distance, the greater the inaccuracy. As to the map, it could work as well, but then you miss the dynamics of using this in combat. Also, the precision does get lost, as from the map, you'd be guesstimating on the position of the target. Consider a non-object somewhere in the middle of a farm field. There is bound to be inaccuracy with the system nevertheless. In order to mitigate it with my method, altitude and distance are the main factors to consider, when designating, especially if precision is of essence. The one additional mechanic that could be added here, would be a hat-command (preferably layered from something already being used) to give the co-pilot commands in the sense of "Further up", "A notch to the right", etc... It could definitely allow for increased precision at range, if one prefers this over creating a new point. In either case, having the "point" selected, you would judge based on where the Raduga-Sh is looking (cross on pilot's sight). To be quite honest, this would permit us to use bombing, and other less accessible features or with decreased accuracy (without a human co-pilot), finally with AI, and efficiently at that. Off the record: The solution with a hat, allowing for incremental adjustments, would seemingly work well with something like e.g. an Apache or F-14 too, as there you can observe what co-pilot/WSO is looking at on a screen. If you need to move that point, give a couple of commands with a hat-switch (talk on), and off you go. The reason I mention other modules, is that the system should be uniform across modules. That way, it remains a learn-it-once and becomes more accessible to most.

I went off memory as to what it was before (APU-6 Vikhr). All correct on Ka-50 Flappie

Absolutely Come to think of it, this was a common intelligence practice of those times, and even nowadays, to operate with different indexes for the same project, so as to confuse any unwated reader. Especially the data sheet you posted there, definitely something they wouldn't want to give away a GRAU-index for. The information on some of these systems is really scarce, even nowadays. Adding another layer of naming, can quickly add to the confusion. It's a particularly interesting topic, especially with what's happened with availability of Russian documents since 2022 and the inhibiting laws. Consider how many iterations of Mi-24 exist, yet how few manuals are publicly available.

That's really where the local language evolved from. In order to simplify talk among each other, instructors, technicians and mechanics would refer to the sustem as a whole, when talking across each other. This is common of such closed groups. Indeed, in daily talk, "Shturm" refered to the "Shturm with Kokon", while "Ataka" was used for "Shturm with Ataka-V". The fact that manuals are propelling this understanding further, is just a byproduct of what was common talk back then. Having it sorted out though, will certainly make pilots more aware of what they are actually launching.

Regarding the types of missions and tasking that can occur in a given mission, it is not always possible to direct the AI co-pilot on a given target (ground feature, default building on the map, etc...). I have been thinking about how this could be solved in an elegant way, and came up with the following: The pre-requisite for this to work properly, is that only manual fire will be accepted (player pulls the trigger). Otherwise, if AI is to commit to engaging, the pilot would have to have a command/action for forcing through the AI's decision on whether to engage or not (hold the trigger for longer, or something similar - that while in auto-mode (not manual)). As to the mechanic, when the pilot wants the AI co-pilot to scan a certain area, he/she places the imaginary reticle at the spot, and gives the order to the co-pilot to inspect that area. What follows after, if objects are spotted, is the pop-up of a contextual menu with target selection list. Here is where my idea for a change comes into play. Why don't we improve that menu, by creating one "default" point at where the cross was when the order to inspect was given? (This is in essence, a SPI-point). Whenever the order to inspect is given by the pilot, the first option to always show on the list, will be "point". If objects are spotted additionally, the list would be populated, just like it works currently. If no objects are spotted, the "point"-option will appear alone. In any case, it would grant the pilot full antonomy with which to chose targets, and not only objects, but just about anything physical (ground, civilian vehicle, default building on a map, etc...). It's really just a matter of just adding the initial point of interest (where the reticle is when the order to inspect is given) as a "targetable" point. This idea, would build further on the mechanic, and be easy and quick to use in nature, especially in dynamic scenarios. It could be applied to other modules as well. zerO

Much appreciated, brother

Following a similar bug report on Mi-24P, the logic of the rearmament screen should have parity across all modules. While Vikhr (9K121) is the whole complex of Vikhr, what it fires is the (9M127) missile. Considering that armament screen shows what type of specific armament is selected, the name should be only (9M127) in the rearmament panel. zerO

There is a rather important mistake in the armament panel of the Mi-24P. With regards to the guided missiles, you are differentiating between Ataka and Shturm. That is wrong, and it brings further confusion to the forums, as well as improper denomination. Shturm (9K114), is the whole complex carried on the Mi-24P that allows firing of either the older Kokon (9M114), or the newer Ataka (9M120) missiles. The name of "Shturm" should be changed to "Kokon", in order to be correct. Just noticed this while looking at it in VR. zerO

I am curious if ED has looked into the possibility of using maps provided by Maxar. Apparently, the company being among the top dogs on the market, have endless possibilities with regards to layering, detail, AI-generated topography and basically a photorealistic scenery. Question is of course how it would potentially interact with DCS´s engine, however I´m sure that they would adjust the export format on a whim. I have to say, Maxar´s work looks too fantastic to not have a look at it. It would be quite the something to have actual, photrealistic maps (detail down to 20cm) for the whole globe. The addition of multiple layers, such as to have access to information that modern military has (albeit with respect to confidenciality), would be amazing.

Fairly sure that ED realizes the limitations of the systems. However, as always, it's a matter of reallocating resources (mostly manpower) to more pressing issues. I wouldn't be surprised at all, if the mechanics behind the newly implemented systems (IR being one of them), are built with future modular support (software). In essence, any future upgrades to the physics and visuals, will be another layer of programming upon the exisisting system. That, instead of a complete rework. Don't worry, I'm sure that with time, we'll get ours.

Where did you exactly check Igla-1 performance in DCS BaD? Sure, first generation of manpads have poor PK, that goes for Red Eye/Stinger as well as Igla-1. Surely you don't mean the strelets on Ka-50 which has 9M342?! That is Igla-S, also known as "Igla Super". Back when it was released, it had a unclassified PK of more than 95%. Classified is most definitely higher. It's hard to compare based on loose data, but Polish Piorun is the most efficient manpad in the west based on feedback from Ukraine. Igla-S plays in that realm, hence why aircraft tactics have changed to long range attacks on both sides. For the record, Verba is entering service for some time now, as a successor to Igla-S. They are pretty much the most efficient manpads in the world, bar none. As to Mistral, its claimed efficiency is 96% PK, however those are synthetic tests. I find no actual combat results confirming these statistics in the field. Assume them similar, since little information from wars ever reach disclosure, and plackards are all we have to go off in case of Mistral.

I imagine that it's the software-side of the suite, which is the bigger problem here. JF-17 was mainly designed by China, but one thing they absolutely did not want to export, was the software of the airplane (cockpit ecosystem). Same goes for pretty much all of their exports. They will sell you the hardware, minus software to control it all (and other components like IFF for example). With the J-8PP, you really have a western digital suite in the cockpit. I wouldn't be surprised if this was the main objection against J-8II. Also, the tricky part with such laws, is that they are written in abstract, meaning that they basically work as a mechanism for persecution. Pretty much anything that walks on legs can be persecuted, should the government/relevant governmental organ, decide so. That's really the problem in most countries overall.

This isn't really my trade at all, so your guess is as good as mine. One thing is fore sure, the models have been verified in multiple ways, and I guess 2 modules have so far in the history of DCS needed a slight correction on the exterior. They do get it right, that's for sure. They do use photgrammetry as well, it has been mentioned around. Beyond that, it's a digital artist's playfield. In VR for example, everything looks correct compared to the actual aircraft I have sat in the cockpit of. This is further confirmed by mixed reality, where overlapping of hommade cockpit and the virtual one, coincide. I wouldn't worry about anything related to this, there is a reason DCS and ED have the reputation they have. Afterall, their commercial side delivers on military contracts. That should grant credibility enough, though it's always important to have an open and critical mind. Don't worry, MiG-29 will be amazing, no doubt about it!