Mad_Shell

I'll provide tracks later. If you want to test it on your side, you just need to put 2 AI against each other at long range.

The improved BVR AI is nice, my only grip with it is it never anticipates missiles launches. It only begins to crank once it has fired its own missile. If the enemy plane has longer range, or even same range missiles, it will always defend too late and die. The AI should take into account what the enemy plane is, what missiles it may carry, and plan accordingly (try some preemptive defending, crank, low alt, going cold and hot again...)

Thank you for the feedback! I think there is a misunderstanding though. According to the lua exporter by Quaggle, there are 2 different versions of the Mistral missile in the DCS files. The file "./CoreMods/aircraft/AircraftWeaponPack/AA_Missiles.lua" indeed uses a value of 4 degrees for the FOV, and a value of 2.2 seconds for the burn time. HOWEVER, the Gazelle in DCS uses the file located in "./CoreMods/aircraft/SA342/SA342_Weapons.lua", where the FOV is 14 degrees, and the burn time is 3 seconds. A few more values are different between the 2 files. That's why in my first post I said that I used the "./CoreMods/aircraft/AircraftWeaponPack/AA_Missiles.lua" file as a basis for my own lua version of the Mistral. EDIT: also, I have a strong suspicion that the parameter of resistance to flares "ccm_k0" isn't working, and has no real effect. No idea if this could be specific to the Mistral, or if it's the case for all IR guided missiles.

The whole jamming environment needs an overhaul in DCS. Burnthrough range is always the same for all aircraft and radars, no matter target RCS, radar power, jammer and radar technology... the AMRAAM never lofts even if the target in within burnthrough range, the AMRAAM seems to remain in hoj mode without trying to get a radar lock (or has no burnthrough range modelled)...

Oops, I forgot a doc yes, here it is! It is written: "Une fusée de proximité qui a pour but de donner l’ordre de mise à feu de la charge militaire soit à l’impact, en détection de cible à proximité, soit en autodestruction." Translated: "A proximity fuse meant to trigger the warhead, at impact, or if a target is detected at proximity, or for self-destruction" For the parameters "SeekerSensivityDistance" and "sensitivity", hard to propose a value without knowing what they do exactly. All I know is that in "Janes Land Based Air Defenses 1992-1993" (I posted screenshots of the relevant pages in my 1st post), it is stated that the Mistral should be able to lock on a non afterburning jet at at least 6km, and on a combat helicopter with heat reduction systems (IR suppressors) at 4km. It is also written that the Mistral seeker is 3.5 times more sensitive than the Magic II seeker. In the Magic II lua file, the value used is SeekerSensivityDistance = 20000 (vs 10000 in th Mistral lua). There is no "sensitivity" parameter in the Magic II lua since it doesn't use the more modern api with a modelled seeker). Last time I tested the Mistral the lock distance seemed quite close to what is specified in "Janes Land Based Air Defenses 1992-1993", so I suspect that it's more the Magic II seeker beeing too sensitive in DCS. Poste_de_tir_Mistral.pdf

Yes I confirm this has been fixed and works correctly in the latest open beta

I up this topic, since Casmo just posted a video showing what rapid fire looks like, and how quickly you you destroy targets. George could do that with what I propose above.

Wait, you mean that as soon as a target is jamming, the AMRAAM uses hoj mode only? And won't ever try to use active seeker?

Hi there. The Mistral missile suffers from several issues and inaccuracies, making it severely underperform. Here is my work, using solid sources, to correct the missile. Note that DCS uses the Mistral located in "./CoreMods/aircraft/SA342/SA342_Weapons.lua" (by Polychop) which is encrypted. So I used and modified the Mistral located in "./CoreMods/aircraft/AircraftWeaponPack/AA_Missiles.lua" (by ED, and with only a few different values compared to Polychop's Mistral) to make my new Mistral version. Here are all the changes I propose, and the sources I've used: - the seeker field of view used in DCS is 14°. That is a ridiculous value. It's 7 times what is used for the stinger or the Igla (2°). Since a larger field of view means that flares stay longer in the field of view of the missile, that also gives an atrocious resistance to flares to the Mistral. That also leads to situations where the Mistral will switch to another aircraft while it's quite far from the intended target... In real life, the Mistral is described as having a very narrow field of view, combined with advanced algorithms, giving it an excellent resistance to flares (Janes Land Based Air Defenses 1992-1993; SAFRAN document on Mistral seeker). I recommend a value of 1°, given the Mistral is described as having a better seeker than the Stinger and Igla in "ANALISIS DEL MISIL MISTRAL INFRARROJO COMO SISTEMA ANTIMISIL Y ANTIAEREO", and the best kill probability of all MANPADS in "MANPADS A Terrorist Threat to Civilian Aviation?" (page 39). - the proximity fuse has a radius of 5 meters in DCS. The document "ANALISIS DEL MISIL MISTRAL INFRARROJO COMO SISTEMA ANTIMISIL Y ANTIAEREO" cites a proximity fuse radius of 2 meters, more plausible for a missile with a 3kg warhead. - the value of K = 2 used in DCS in the autopilot part, is too low. For a short range missile, many articles explain that a value of K between 3 and 5 gives better results (see the attached article "Proportionnal Navigation Guidance"). The AMRAAM in its terminal phase uses K = 4 in DCS. Based on my tests, a value of 5 gives the best results for the Mistral (https://cdn.discordapp.com/attachments/925038843399376917/955940311354454056/K_effect.mp4 ). And I know it's not definitive and documented proof, but one would wonder why MBDA would not give the better guidance to its missile... - the flag_dist = 150 parameter is too high. It leads to the missile brutally diverging from its target if the target is flanking (see example K = 2 in the video). A value of 50, like the one used for the Igla, combined with K = 5, gives the best hit probability (see example K = 5 in the video). - the GimbLim parameter has a value of 30°. I propose a value of 38°, based on "Janes Land Based Air Defenses 1992-1993", which cites a gimbal limit of 38° for the Mistral 1, and the SAFRAN Mistral missile seeker document citing a >30° gimbal limit. - for omega_max, which is the maximum angular tracking rate of the seeker, I propose a value of 20°/second, as stated in the SAFRAN document about the seeker. - The rocket burn time should be about 2 seconds, rather than 3, based on video evidence ((https://youtu.be/KK9_Iq0AM9k?t=15 ; https://youtu.be/RY78aBlUkMQ?t=27 ). - I add that the missile should self destruct after 14 seconds of flight time (fuse confirmed to self-destruct in the document "poste de tir Mistral", and 14 seconds max flight time cited in "ANALISIS DEL MISIL MISTRAL INFRARROJO COMO SISTEMA ANTIMISIL Y ANTIAEREO". - As a bonus, it would be great to see tha shaped trajectory added. The Mistral is designed to have a shaped trajectory (it climbs a bit just after launch, see photo attached). This is especially important to engage enemy helicopters, as it allows the missile to continue to track them even if they try to terrain mask. You'll find attached a lua file, which is the ED's Mistral file with all the parameters corrected with the values I propose. Some things I haven't included in the lua are the self-destruction at 14 seconds, and modifying the "SeekerSensivityDistance" and "sensitivity" parameters to match a 3.5 times better sensitivity than the Magic 2 missile seeker (according to Janes Land Based Air Defenses 1992-1993. That's for the Mistral 1, but the Mistral 2 we have in DCS basically has the same seeker.) SAFRAN_Mistral_Seeker.pdf ANALISIS DEL MISIL MISTRAL INFRARROJO COMO SISTEMA ANTIMISIL Y ANTIAEREO.pdf Proportional_Navigation_Guidance.pdf New_mistral.lua

Yeah, would love to see George use LMC or IAT when own helo and/or target are moving so that he misses less in those situations.

We need more realistic stats for many ground units. Examples: in DCS, AI tanks can't hit anything when on the move (try to make them shoot at an enemy tank 2km away while moving at 40kmph...). Try driving a tank and do the same: really hard to hit too. In real life, during exercises modern MBTs have more than 95% hit rate in the same scenario! Another thing about tanks: reverse speed are all wrong! In DCS tanks reverse speeds are less than 10kmph. In real life they're between 30 and 40kmph! This is super annoying when you're trying to do real life tactics, such as shoot and scoot, or reverse in front of an obstacle. Finally, the artillery needs a global overhaul. The accuracy (AI or player controlled) is often way worse than in real life. When aying an arty unit, the fire control is super, super basic and could be improved to allow more accurate shots. Finally, the AI arty could be created (I say created because it doesn't exist) because AI arty never, ever fire on their own, even when friendly units have spotted enemies well within range...

Just did a test with an AI AH-64D block II: the AGM-114K it has fired continues to perfectly track the enemy tank, all while the Apache was destroyed only a few seconds after the missile was fired. No other unit lasing the enemy tank. Track attached. PS: I haven't tried if it works for Hellfires launched by players, if someone can test that it would be great! PS 2: to add a bit more details, once the AGM 114K loses the laser spot, the missile seeker should continue to point at the last laser spot location, ad the missile should align itself with the seeker to go straight toward the last laser spot location. That's the method used to reacquire the laser spot in case the missile climbs too high in the clouds and doesn't see the laser spot anymore. Source attached (public). bug_AI_hellfire_continues_track.trk hellfire_article.pdf

The main problem I have with the current BVR ai is that they always work the same way: Go straight to the enemy and climb at 11000m, no matter the plane (planes like the Mirage 2000 would fly higher realistically). Then either they have time to launch a missile, and always crank and dive, no matter what the enemy plane is (why dive and lose altitude if the enemy plane has no BVR missile? Or way inferior ones?) Or, the enemy plane launches a missile first, and the ai only begins to evade when the missile goes active, which is usually too late. They don't anticipate a missile is probably already inbound based on the type, aspect, altitude and speed of the enemy plane.

+1 During my last mission George needed 3 Hellfire to kill a non moving T-72 located 6 km away.... I was in forward level flight, as stable as you can be...

I mean, to me it's a bit like if a module has a wrong flight model and its top speed is too high, and you say "just don't go full afterburner and you'll get the right speed." Yes, it's possible. But should we have the realistic option in the game? Imo yes. And that would be nice for mission designers and server owners who would want to do that too.

In DCS it's possible to rearm and refuel a jet/helicopter in only a few minutes, or even less. Repairing a heavily damaged aircraft in a few minutes only is also possible. Now, I understand this is for gameplay reasons, and no one wants to sit for 1 hour waiting for rearming. However, hear me out: - refueling a jet/helicopter only takes between 5 and 10 minutes (sources: https://www.ang.af.mil/Media/Article-Display/Article/862807/f-16s-fast-track-through-flight-line-fueling/#:~:text=Keeping the F-16's engines,to less than 45 minutes. and a discussion with a Tiger helicopter pilot) - fast rearming (integrated combat turn) can take less than 15 minutes for jets (sources: this comment from ex ground crew "FYI... An actual "ICT" involving F-16 Loading: 6 MK82's , 2 AIM 9's, 510rnds ammo and chaff/flare, as well as refueling takes Approximately 14 min. The fastest I witnessed was 12min 34 sec from chock placement to chock removal. ( Homestead AFB July 1985 to Jan 1988)", https://www.saab.com/products/gripen-c-series stating a 10 minutes combat turnaround for the Gripen) - having to wait 5 to 15 minutes for a complete rearming/refueling procedure would force players who wish for more realism to deal with real life limitations. No more "2 minutes on the ground and I"m back in the fight!". Now, fuel management matters more, weapon usage has to be more careful. Like in real life... Eventually, it will be especially useful for the upcoming dynamic campaign, for players who want to deal with realistic limitations. Questions like fuel management, how to manage weapon usage, do I have enough time to land and rearm now? are part or combat operations, and an option for realistic rearming/refueling times, and no magic repairs, would require little effort and be a nice addition.

Hi BN. My main grip with the current BVR AI is that when it launches a missile, it will always immediately crank and dive. While cranking makes sense, diving should only be a thing if the AI thinks there is a possibility of incoming missile. If the enemy aircraft is identified (RWR) and has no BVR missile, or ones with smaller range, diving is a bad decision, as you give up you altitude for nothing. If it hasn't fired a missile yet, the current BVR AI also never defends before an enemy missile goes pitbull, which is too late most of the time.

- NATO planes fire red tracers IRL, but most of the time they have no tracer ammunition. Loadouts with yellow tracers are in no way realistic. Default should be no tracer at all. (https://www.reddit.com/r/hoggit/comments/v4szxn/reminder_that_western_fighters_use_red_tracers/). It can be hard to find documents on that stuff, but please ED, ask your SMEs. - All the rounds used by ground units and infantry are tracers. Every. Single. Round. Any fire exchange looks like Star Wars. In real life, no one do that, except for some specific units (anti-air artillery generally use all tracers belts). Usually something like 1/5 rounds are tracers (that ratio can change, but that's NATO standard), and sometimes the grunts put a few tracer rounds at the end of the cartridge clip so they know they have to reload. Note that in DCS the coaxial machine gun on the Abrams, correctly uses a 1 tracer / 5 rounds belt. The new door gun on the Hind also uses a 1/4 or 1/5 tracer ratio. - CIWS on ships use no tracer ammunitions in real life. Only the ground version does use red tracers. Once again in DCS, ships fire a nice stream of yellow tracers. In one of the recent cinematics, ships use red tracers. Still wrong. This page contains nice infos on the CIWS system and ammo: http://www.navweaps.com/Weapons/WNUS_Phalanx.php#ammonote3 . Also, haven't found a single video showing tracer rounds on naval CIWS.

Mid-air missile explosions used to produce a white smoke cloud, but recently it has been changed to a way darker smoke cloud. I don't know why this change, since there are tons of videos showing that the produced smoke puff is white, or at least very clear. Here are some examples (timestamped): For comparison: old DCS effect: New DCS effect:

@BIGNEWY @NineLine The message above is commercial advertisement.

Great! Thx for testing it!

Hi! I have no access to DCS currently, so could you check if releasing flares at night has any effect on AI spotting?

There is indeed a patent by the AMRAAM manufacturer, written just when the missile deliveries began, that states that the lock gates will continue to follow the predicted target position and speed for a few moments, even if the lock is lost. Also, it seems rather logical to keep the lock on a target even if the radial velocity is small if the missile can see that target has already locked it, and that the target is alone.

Mmmmh, not sure it's the right approach. Once the target is locked and if target signal is not rejected (no notch or look-up condition), the range/angular/speed gates should remain on target even when its radial velocity is small. Also, methods to reject chaff are more based on the missile predicting target position, and chaff falling out of that position (chaff quickly loses speed and ends up way slower than the target), thus out of the lock gates. Maybe the missile won't at first lock a target with slow radial velocity, but once a target is locked, it should hold the lock even with low radial velocity if in look-up condition. I can't imagine the designers making a system where the missile will lose lock each time a target hits low radial velocity, no matter the intercept geometry...

Hi! I hope trees become destructible then, because anything 12.7mm and more should go through even quite big trees if AP, and shred them if HE. If the problem of trees remaining intact while bombs and ATGMs hit them is extended to rounds, that'll just be even more frustrating.