zerO_crash

No, the actual reason why you got the generator failiure, was because you let the main rotor RPM fall below 87% (absolute minimum 85%). The reason is that generators are connected to the main rotor. However, when you engage PZU and anti-ice, it pulls more energy from the engines, effectively reducing the engine's available power for driving the main rotor alone. Consider that generators connected to the main rotor will act as a physical load, and more so when higher electricity levels are required. Simply put, one of those instruments that you have to monitor constantly, is the main rotor RPM. You do that, and reduce the collective when rotor RPM falls close to 87% (again, 85% absolute minimum), and you're good. Remember, that much of the success surrounding successfull helicopter operations, is correctly planning for weight depending on the flight profile. There are restrictions on MTOW depending on weather, temperature, altitude, etc. This has to be closely considered by a helicopter pilot prior to commencing the mission.

There aren't "weird" people on these forums, rather the more and less interested in the topic. Just as any forum, the discussions can often circulate with misundsrstandings coming from language barriers and lack of precision in formulating oneself. Here was an example of the latter. With that said, it got solved in the end. Seeing you being new to the forums, Klingel, I'd be careful on attempting to make a qualitative judgment. Knowledge accrued through years of trial and error, reading up on topics and talking to professionals, is being shared online for free. Patience is required from both sides. Know however, that new members do not set the tone here. While Admiki might have come across as harsh, the act was in the best of interest, pointing out the importance of detail and semantics. This is of essence when operating in the realm of DCS with such advanced modules. Finally, Martin, a word of advice; be careful as mods can mess up other parts of the simulator. There are more than enough threads regarding bugs and glitches caused by mods. Keep that in mind if you decide on installing any. Thanks Flappie, I'm actually surprised that it wasn't reported earlier. Good stuff! With that, let's consider this thread case closed!

Thanks for chiming in Vibora, I appreciate it! Absolutely, take your time, and of course decide whether this would be of interest to you. I know there are many requests with regards to other variants of F1. The main reason why I ask specifically about the French C variant, is because it seems that the module is practically designed today with the F1CE. As I understand it, there are practically no changes to be made, other than a few aesthetic ones. There is something neat about having an aircraft made in an original variant used by the country which developed it (France). Great work so far on the current Mirages, both in quality and commitment. Keep at it, we'll see what the time brings!

@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.