zerO_crash

There have been made many promises with regards to a dynamic campaign/mission generating environment over the years, and for whichever reasons, those this feature gets delayed often. Understanding and accepting that, I wish to make a request for possibly releasing mission persistency ahead of the former (I imagine it would be easier to implement). Essentially, have extra parameters inside the .miz folder which would include the information on; a) initial existing units, b) current existing units (not destroyed) and c) destroyed units for maintaining damage models. The above-mentioned parameters would somehow have to be updated (overwritten) as the mission is run, such that the progress would be maintained. For example, set a 5 minute interval, with additionally a final save upon the main host (MP/SP) leaving the mission. I realize this is much to ask for, but it would open up for more complex mission scenarios, while ultimately waiting for the dynamic campaign/mission generator. Thx!

There is a difference between what it "should" and what it "will". As I have already spoken with PilotMi8 on RU-side, there are numerous functions modelled in the Mi-8 (and Mi-24) which mimic real aircraft imperfections. As such, manuals (IRL) have always been guides, more than anything else. They are not consecutive with respect to individual aircraft. As such, for the speed hold, I've seen the AP fluctuate in performance, but a 15-20km/h deviation results in practically instant correction. Therefore, it works, and is actually simulated as per realistic individual properties, rather than a theoretical scheme described by the manual. This discussion goes very much into what we've discussed before about the main rotor RPM threshold. One thing is the manual, something else are practical considerations. In the same way, I noticed recently that during heavier loads on engines (winter - much electrical equipment needed plus worse thermic characteristics), upon pulling in more collective, the power synchronizers will not be able to keep up. That's to say - one engine (left) will be be at higher RPM, than the right one. IRL, this is the case (engines are almost never even), thus individual differences between both engines are modelled.* * Point being, go ahead and check yourself, but nothing is ever precisely as described by the manual. As an instructor myself, that is both from experience as well as military pilots claim.

In ME, on the bottom bar, to the right (from the screen centre), you have wristwatch-icon. Deselect it.

My pleasure!

Granted, MD530F Cayuse, but it shows the conduct of attacks using machine guns in the same manner that Kiowa Warrior is used. Really good training material:

Mi-2 will have to come, no doubt there! Fantastic aircraft, and very unique to the Soviet doctrine in that it is a light helicopter, yet different variants retained capabilities found on heavier Mi-8 and Mi-24 helicopters. Would be awesome indeed

This one is decent too. There are indeed in Russian, but then that helps little to those who don't speak it. Some good ones have been removed over time (war).

Flight control system. It would be interesting to get any information about how unstable this helicopter was without electronic FCS. There are helicopters which exceed its agility (maneuverability) and speed, but it still is pretty impressive given that the construct mainly focused on stealthy radar characteristics. It was a nice machine without a doubt, but really failes at its main objective. Then there is the question of just how reliable it would be, and maintenance oriented. Moving cargo-doors, possible RAM coating on the helicopter (that would be a costly business in desert-climate with sand peeling off the rather delicate coating), and much more... Yeah, difficult to say, but surely an expensive toy.

Well, actually, we know they existed. Whether thet do now, is simply not known, nor have they been seen. They were EH-60s, electronic warfare variants of UH-60s with altered appearance for somewhat reduced radar signature. Very little is known overall, other than the extrapolations that can be pulled from the one picture of it (there is a second picture showing the crashed one's tail, but the fidelity leaves a lot to be desired for any meaningful analysis). Some basic geometrically reflective covers, along with a possibility for RAM-coating (based on how matte the paint looks). The tail antennas from the EH-60s are retained, pointing at this likely being the major ace-in-the-whole, essentially a radiowave jammer. Still, there is no talk of efficiency (likely a cumulative effect of all the technologies and NOE-flying), nor has there been any formal revival of a helicopter with stealth-characteristics. Furthermore, the main component making any helicopter prominently visible to radar, the rotor, is still there. If it truly was to go for stealth, a fenestron tail rotor is categorically a number one choice due to the shroud covering much of it from frontal aspect, as well sharp tips of the blades (notice what tail rotor Comanche had). Besides legends of legends, there is much in physics that would indicate this to be a interesting helicopter, and nothing more. Here is an article with the corresponding picture of the surviving one posted: https://www.twz.com/35342/this-is-the-first-image-ever-of-a-stealthy-black-hawk-helicopter

In the ME, if the "show only historical units"-option is enabled, it seems that OH-58D does not show up as a selectable unit. I tried with the mission set to years 1995/2000/2006/2015/2020, to no avail.

People are funny... It is a customer's right to complain and ask for reiteration where it is due. It is very logical to ask for explanation when a module releases at $70, yet retains basic quality issues. Overall, the OH-58D is solid in terms of systems, FM and features. In terms of textures and sounds, those things are not bugs. They are apparently underprovided. If one looks at the complexity of AH-64D or any other module at that price range, then KW is both smaller (physically), far less advanced in terms of systems, and generally has fewer aspects to consider (integration of external DL and such - L2MUM is a good example here). If disagreeing with a thread, it's very easy to move on without responding, or feeling the need to express oneself. It is, thanks to demanding customers, that sound will get revised now. It also does point to Polychop taking a dangerous approach regarding quality-only-per-request. If better accoustics were initial plan, then they would be in it at release. Therefore, recognizing that the overall module is very good, but falling somewhat short of $70 in comparison to what you get elsewhere, let's hope that shortcuts in development will not be the new norm. To those who still disagree; your welcome! Free passangers benefitting off the diligence of others! Orherwise, if you are on the edge - don't worry, it's a good product, but it will truly shine when the above gets mitigated.

I'm ultra-bright, point still stands, Francis

That explains. One is unable to to see the sight when pointing the M4 far off the centre-view in VR. It's either too high up or too lowc depending on elevation. Kinkkujuustovoileipä, I got a suggestion: The aspect of controlling a weapon properly, is based on having two reference points. One closer, one further. If those two overlap, the optical sensation of aiming down sights will be accurate for such aiming. As it stands now, the M4's further point, is controlled by the mouse, which is good. The closer one, however, is tied to a invisible bubble to left of the co-pilot body. Here lies the problem. If you tie this point to the location of the co-pilots head/eye, the corresponding line will be aiming down sight, regardless of whether you move your mouse or head (VR). Have a look: This is the current situation: This is my proposed change: If possible, have the current mode (the upper one, weapon lowered) be the default one, with the lower one (second picture) being the "aim-down sights". If this is doable in DCS, it would work well

The controls are actually somewhat weird for this. By default, "MOUSE 2" is bound to "switch down" for flip switches. It is a general binding. For whatever reason, I cannot get the aim-down sights to work. I can only unstow the weapon, and fire it semi-blindly. Using VR btw. One thing I wonder about in addition, if you use up the M4 ammunition and RTB for rearming, upon opening the rearm-window, the "ammunition" shows 50% left. That is without any the M3P attached.

You truly grasped the essence... I am comparing altering individual FFB-effects to that of changing the properties of a FM to your liking. For example, co-axial Kamovs (Ka-50 included), have a force feedback system which gives prevents the pilot from overlapping blades. As you gain horizontal speed, a resistant force will grow in strength, with the centre of it being front left cyclic (worst position) and right-pedal (also worst). You could very quickly ruin this feedback (that is, once it is modelled, as it's currently not). Other instances will be effects like tightening controls as you fly a typical fixed-wing, so as to prevent abrupt movements of the control column, possibly bending the airframe or cusing catastrophic failiure. A big part of the complexity of military aircraft, lies in the design and feedback from the control column. If you cannot see the the realationship, then I cannot help you. To each their own - bad setup will cause bad habits.

Splendid! I do admit that the Kiowa Warrior currently is less noisy than a 50cc scooter. It'll be interesting to see what this cooperation results in!

Brunner software alone costs €500, unless you buy a Brunner product, in which case it follows (for private use only). As someone who owns everything Brunner: CLS2SIM can do anything you want. With that said, it achieves it by emulating it in the software. CLS2SIM has never been a solution wirh DCS, due to the complexity of of flight systems, autopilots and just about anything that can affect aircraft controls. DirectX-support is needed for any aircraft more modern than WWII or a Cessna. Trimming, is one of the first areas which prove the worth of two-way feedback with DirectX vs. proprietary software. Therefore, DirectX is the only way to properly do DCS with FFB. I notice many mention customizability with different FFB software. Well, initially, you have to ask yourself why you fly DCS at all, and not Ace Combat. Changing individual FFB-effects, is equal to that, of altering the flight model of an aircraft to your liking. It unrealistic to start altering dampeners and forces, when IRL, the most you "might" be able to do, is to disable force trim/change general strength of forces acting on the controls (not individually). Often, getting to understand the flight control of an aircraft, leads to better understanding of the aircraft itself. I see it as the dev's job to adjust the FFB effects properly, so as to mimic the ones of the real aircraft. Many military aircraft don't even have individual adjustment for feedback. As they say; "What you see, is what you get.".

Splendid! That's good to hear

Congratulations on yet another fantastic module. The FM and general impression of the module is superb! Well done! I would like to touch on the topic of damage modelling, as it seems to be on the lacking side for both Sa-342 (the only light helicopter I fly), as well as what I have observed with the OH-58D. Given that this is a combat aviation simulator, Polychop will have to take a closer look at proper damage modelling (not only internal components, but actually external damage and how FM is affected).

Gotcha! Much appreciated!

Sweet stuff! It's starting to take a real shape now. It'll definitely be interesting to see what you have achieved, primarily with the MEDUSA. @The_Fragger, as I understand, you changed your initial stance on which versions of the BO-105 are going to be made. Without scrolling through the whole thread, is it correct that the plan is now to make PAH1A1 as well as HKP-9, meaning the ROK CBS-5 (if I recall correct) has fallen out?

Everything can be compared to everything. Manpads, however, have two stages, which negates some of the initial recoil (and thrust plume). There is a impulse motor meant to eject the missile from the tube, and at a safe distance/orientation from the operator, followed by launching of the actual sustainer motor. In comparison, Hellfire engages its main thrust immediately upon fire. There are more differences overall, which make the comparison off. Well, the words of Nick Grey were such that DCS should represent the flying qualities of aircraft in a realistic manner. Each and every module is stated as the best available, and in the progress of becomming yet more realistic as a representation. While things are missing (i.e. being worked on), simulators have taken over for practical training and exercise in just about any domain where approach to realism is necessary. I definitely see the points that YoYo is making. This isn't a matter of time after release, but rather constructive criticism where it is due. I'll remind all that when SA-342 Gazelle released, there were already early indicators that something was off (FM). While OH-58D is a really solid product, there is definitely room for improvement and feedback.

As it stands currently, upon hovering with a helicopter over pretty much any type of ground, creates dust. That is completely wrong, as hovering over grass/rocks, should not produce the dust (it all depends on the type of soil). Effectively, anti-dust devices are a must-have on helicopters whenever hovering is planned. This is a known issue, but I'd like to ask for it to be moved up on the priority list. That, mostly due to how it affects primarily helicopters. On the other hand, flying in dusty climates (hot and arid), there should be both brown-outs as well as enough dust particles in clean air (and OGE), so as to require the use dust-filters practically at all times. Hope this gets more attention soon.

The point is; before instagating any improvement, one has to first recognize a problem. With that said, I doubt that this is a high priority with ED (or 3rd party, depends how one wants to fix it). Still, if it's categorized as a shortcoming, a solution will eventually happen. The question is really whether this should be a general "physical-model-disables-LOD", or individual module adjustment, resting squarely with third-parties.

Absolutely not! It has to get fixed.