Crescendo

I was inspired to make a thing: - - - (In case you don't get the cheesy joke, I recently watched and on YouTube.) Enjoy! :pilotfly:

The purpose of the Sparrow is to demonstrate your superior abilities as an Airborne Samurai. With this most civilized weapon you will joust the chivalrous skies and deliver eternal shame upon the fox-three scrubs.

+1 Great guide, tjhowse. Rep inbound! I used to be like this :joystick: , but now I'm like this :thumbup:

There's nothing wrong terminology/jargon. I do agree with you that speaking only in terminology is not very helpful to new players, because those new players have no prior knowledge and may not have the means or ability to easily find definitions. However, this is most definitely not an argument against using terminology. Terminology is critically important because it is a convenient means of talking about precisely defined ideas and concepts. If we all understand and agree upon the terminology, we can have a discussion. On the other hand, if we have no terminology, we must continually create and recreate our own personal definitions, and this means we forever run the risk or talking past each other, of not really knowing if we actually understand each other, and of needlessly 'reinventing the wheel' over and over. Now, if some of us don't understand the terminology, it can be explained to them, and it then becomes a very powerful mental shortcut that accelerates learning and information exchange. Terminology exists in every human endeavor for a reason. You said yourself that you try and leave out the terminology, yet not only did you use the terminology "3/9 line" (which has a precise definition), you used the terminology incorrectly (no biggie, we all make mistakes). However, when <Blaze> corrected you, you doubled down and said that "crank is also keeping them on your 3/9line, same thing", which is just wrong. So despite your efforts to simplify and use every day language, you ended up creating more confusion than there would have been if the correct, precisely defined terminology had been used. The solution here is not to abandon terminology, nor is to impugn terminology as some elitist language that acts as a needless barrier to new players. It's true, I concede that some people with a 'clubhouse' mentality may wield terminology as a weapon, but they are not the majority. In my opinion, the solution is is to keep using terminology, but also to remain vigilant in tempering that terminology with newbie-friendly explanations when the context requires it. We sometimes forget to do this, so it is always good to be reminded. In any case, pr1malr8ge, I don't mean to wade into this thread and re-open old wounds, but this does seem to be one of those perennial topics, and it was just a bit much to see someone get the terminology wrong (which, again, we all do sometimes), yet then use that as a jumping off point to argue against terminology.

I won't go point by point, as that can be tedious for both parties and devolve into pedantry. Suffice to say I understand your point that in your industry the system is the system (whatever it is) and it works well enough, although it isn't perfect and there may be consequences resulting from that imperfection as you noted. Hypthetical: Should a person who passes the industry selection processes and is otherwise fully competent as judged by the industry, instead recuse himself because he considers himself to be an introvert? To be clear, you aren't saying this and didn't say this, but one interpretation of your response to me is that because the selection process is workable but imperfect (i.e. someone more towards the introvert scale may slip through), the OP probably ought not to apply because he may be one of the 'false passes' that endangers people's lives. I don't understand what you are referring to or getting at here. You said part of a selection process means passing tests as outlined by you in your previous posts. All I was saying in the part you quoted is that if someone doesn't pass a test, the failure itself should not be considered an out-of-the-ordinary shocking event, unless you're a narcissist who thinks success is 100% guaranteed. People fail things for all sorts of reasons all the time. OK, this wasn't explicitly clear in your post ("could lack the key assertiveness required for certain situations" - emphasis mine), so it is. I find it hard to agree with these statements. Admittedly this is possibly an argument from incredulity. Admittedly I am not an expert, I don't train aircrew, I don't design the tests to select good aircrew, I don't have years of industry experience. Yet, I don't see anything about being an introvert that limits your ability to take charge and assume leadership positions in professional setting, stressful or otherwise. There are plenty of high-profile introverts in stressful leadership roles. You say that introverts can allow themselves to be pushed around, but you could also turn the situation on its head and say that extraverts can push people around unjustifiably, and that that's the problem. I suppose this would fit the "unstable extrovert" archetype. This same pushiness could also be attributed to the "stable extravert", even though they are more likely to make the correct decision. Still, the stable extravert may assume they are correct, take charge confidently and win the allegiance (or obedience) of others, and then promptly kill everyone. My point is no one should push anyone around for the sake of it; ideally (key word) it should be rational and meritocratic decision-making rising to the top. Further, assuming "stability", the extravert will still have a tendency to take charge (which can go wrong as we have seen), and the introvert will still have the tendency to submit (which can go wrong as we have seen). Both are weaknesses depending on the context. So, why is the weakness of the extravert minimized, yet the weakness of the introvert maximized? Is it because the industry prefers a take-charge leadership decision to made right now, even if the decision is wrong? Is it better to confidently pull back on that stick until we stall into the ocean, or is it better to indecisively argue if we're doing the right thing? I can see why it might be better to do something rather than nothing (the "something" may be the right decision even if made for the wrong reasons), but we can all agree both situations are not desirable. I guess I don't see why stable introverts in professional setting can't be trained and drilled with good CRM practices to overcome their weakness and conduct themselves assertively, just as the stable extraverts in a professional setting can't be trained and drilled with good CRM practices to ensure they address their weakness and listen to others when making a decision before potentially blinkering themselves.

Yeah, because that's a fair characterisation of what people are saying. :doh: Validity of personality testing (which is a grey area itself) and financial issues aside, I don't see any reason why a person can't apply and submit themselves to any selection process. What's the worst that can happen? They say no? Big deal. Any sensible and properly prepared person will realise that rejection is always a possibility. If he passes, then presumably he will be just fine as a pilot by your metric, because this life-saving personality test is so rigorous and scientific after all. You said yourself there is such a thing as an extroverted personality type that is not ideal in the cockpit, so clearly being introverted is not necessarily an immediate deal-breaker.

There seems to be a grave misunderstanding by some in this thread of what an actually introvert is. Being an introvert does not mean you are shy, have poor communication skills, lack leadership potential, lack social skills, and lack confidence. Not at all. An introvert can excel in all those areas. All being an introvert means is that you require regular periods of solitude to relax and recharge your mental energy. This is as opposed to an extravert, who recharges their mental energy from regular periods of social interaction. There is no reason why an introvert cannot become a pilot, military or otherwise. That said, the introvert will always have to push themselves harder than an extravert. Socializing and networking is important professionally, and here the extravert has it easy because they find regular and sustained social interaction effortless, while the introvert often (not always) has to overcome significant inertia to feel like socializing. Overcoming this inertia requires willpower and metacognition, i.e. the ability to think about your mental state (which you should be practiced at as an introvert) and recognizing your moods and thought processes. You will regularly have to 'force' yourself to socialize and network for the betterment of your career, and it will be up to you to detect your moods and then decide if you are willing to expend your mental energy or not. This all seems unfair sometimes, but remember that everyone has their own set of problems - introverts and extraverts alike. Moreover, don't forget there are advantages to being introverted too. The key here is to recognize the challenges of your situation and equip yourself with the tools of metacognition. Understand that there will be times where you don't want to socialize, so come up with a system that will make you do it most of the time anyway. Expect difficulty and adversity and preempt your inevitable mental states. If you do this it won't be so bad. Take a page from the philosophy of Stoicism and you can work towards offsetting many kinds of adversities (read Meditations by Marcus Aurelius as a primer). It sounds to me that the big hurdle is already over. If you are as passionate about flying as you say you are, you will be able to offset and endure the discomfort of not experiencing as much solitude as you naturally prefer. Leverage the passion and emotion you feel, and convert it to a well of willpower that you will draw upon in tough times. And consider yourself lucky for finding your passion.

Can we please try to limit the casual sexism? Not everyone who visits this forum and reads threads like these is 'one of the boys'.

I'd like to know the answer to this too.

That's just not true. You're taking a very simplistic view and are willfully ignoring what other people have tried to tell you. One example: Your RWR will detect a fighter's radar emissions at >100 NM and display a threat symbol, but that fighter is far enough away that he won't have enough radar return to detect you. Second example: In a tail-chase situation of >20 NM (or thereabouts), your RWR will easily detect an emitter behind behind you, but they will not be able to detect you even with the correct PRF setting.

I'm not saying that the problems being talked about aren't real, nor am I saying that kinematics are the only problem. Furthermore, I'm not actually talking about realism and balance whatsoever. I certainly do not advocate making the game 'balanced'. War is not balanced or fair; each side can and should try to use the best weapons, technology, and tactics to completely dominate their enemy. What I am saying is that even if all missiles were 100% realistically modeled (all missiles, not just the AIM-120), from one perspective these missiles will still be "useless" when players learn the new missile envelopes from testing and playing the game. Rare exceptions aside, having realistically implemented missiles will not improve your K/D ratio unless the other side is criminally stupid and makes no effort to adapt. On average the better pilots will still defeat the less-skilled pilots, the only difference will be the precise tactics and engagement ranges used in the new missile environment. Exactly. Although to be clear, I do advocate making the missiles as realistic as possible, and I do not think the game should be balanced. My sin here is making a point that is only tangentially related to this topic, albeit one that is in my opinion quite illuminating about the mindsets of some people who get involved in these reoccurring missile performance arguments. I'm talking about the people who take partisan positions about their missiles for their aircraft of choice. I think these people, and it's a not-insignificant number, want their missiles to be as realistic as possible because they think it will help them get more kills (fallacy), not just because it's the correct thing to do in a simulation context.

If we assume for the sake of argument that the AIM-120s kinematics are worse than they should be, what happens when they're corrected? A player's K/D ratio may go up for a time because their opponents aren't used to the increased missile performance, but it will drop back again when the opponents adapt to the change. For example, say that the average Minimum Abort Range for an in-parameters AIM-120 shot is currently ~10 NM or less due to poor kinematics. If the kinematics are improved, the new in-parameters MAR may become ~15 NM (or whatever). Therefore, for the first few weeks this difference of 5 NM will catch some people out, but they will quickly realise their mistake and act accordingly. When this adaption occurs the missiles will be just as "useless" as before. The only difference will be that the average range of a typical BVR engagement will increase, and that there will be less chance of escape if you get caught with your pants down. This is what gets me about this entire missile performance argument. Yeah sure, maybe the missiles suck, but guess what? Everyone is using the same missiles (relatively speaking) so the fight is fair(ish) and the average engagement ranges are well known by all parties. There are no 'secrets' in this game - anyone can test anything they like. Then, when the missiles get better, your enemy has access to them too, you'll kill or die just as much as you did before, and everyone will learn the new average engagement ranges. I honestly think that some people imagine that when missiles are improved, somehow they alone will be the only ones who realise it or have access to the new weapons, and subsequently they'll 'magically' start to get more kills. Funny how the human brain works.

Based upon my experiences, learning BFM is not really something you can hope to achieve by reading books and guides and watching YouTube videos on your own. Frankly, most of this is a complete waste of time. The theory is necessary, obviously, but you won't be able to apply it without learning how to visualise what it all looks and feels like from within the cockpit. You get this by doing, by flying 1 on 1, preferably against a human opponent who is more skilled and experienced than yourself, and who is hopefully willing to provide instant feedback when you screw up. This feedback is critical. Absolutely critical. Without it you'll be lucky to amount to anything, and if you do, it won't happen quickly. Or, maybe you just so happen to be really good, but then again, it's funny how everyone thinks they're great, isn't it? In any case, without feedback you risk practicing and 'perfecting' substandard techniques, you risk not being able to identify your mistakes so you can learn from them (and how to learn from them), and there won't be anyone there to reinforce your performance when you get it right. No fighter pilot learns by themselves and you shouldn't either. The wheel doesn't need to be invented every time. Wherever possible and necessary, real-life BFM training occurs with an instructor sitting in the backseat telling the student what to do, what not to do, when to pull etc. What better way to learn what BFM 'feels' like? If you want something like that your best bet is joining a virtual squadron or asking around in the various TeamSpeak servers for someone to fly 1 on 1 with. Maybe someone who knows their stuff will help you sharpen your skills, or at the very least you'll find someone to fly and share ideas with. The problem of course - and it's a big one - is that a lot of people think they're good at BFM. They're not. A lot of people read a little bit about BFM and then they go burn holes in the sky at corner speed and think they're achieving something. They're HUD fighters who just align lift vectors and pull and pull and think that makes them good. There are almost no masters out there, really. Not ones who you find easily online anyway. If you really want want to learn BFM, I suggest joining certain parts of the Falcon BMS community and flying online and using TeamSpeak with them. In my opinion, there is a higher proportion of people in the BMS community who are serious about BFM and actually know their stuff. It's a different world in those communities and on some servers. That's my opinion, take it or leave it - I'm not going to argue with anyone who disagrees. By the way, if you think I must be good at BFM, you're mistaken. I suck. I am a 'theory reader' with knowledge from textbooks, but with no will or means to actually gain practical skill.

You're correct, thanks. Chalk that one up to a brainfart on my part. :doh: --- Two things I would still like to know: 1. Why are some fields inaccessible? 2. Why are some controls seemingly duplicated?

Thanks for the reply. I have this too. For example: There must be an underlying logic as to why this is the case. I don't know anything about scripting so I won't comment. Any developers care to chime in? I'm not sure what you mean by this. As far as I can see there is no "Throttle" category. I can change the category to "Systems" and this will display the systems controls including engine start/stop, but this is just a filter to manage the large number of controls. If you're talking about ensuring that the throttle column is selected, you can see in my screenshot that it is. Care to elaborate? I tried clearing the throttle column. Doing this does remove all throttle binds, but the inaccessible fields remain.

If it's a matter of this being a repeat topic, can someone direct me to the old threads? I've tried searching the forum, but none of the search terms I use yield anything useful.

Hi all, I recently performed a clean installation of DCS 1.2.8 (including deleting my Saved Games "DCS" folder). One of my reasons for doing this was to start fresh and create completely new ".diff.lua" control profiles. I had hoped that this would enable me to move away from the tedium of troubleshooting my control profiles after every patch. However, after re-installing DCS, I am still seeing symptoms of what I understand to be faulty control profiles: highlighted, inaccessible fields. Refer to the red circle in this picture: These circled fields cannot be assigned keybinds. In this particular instance the effect only applies to the "Throttle - HOTAS Warthog" column, but there are multiple examples of the inaccessible fields in every column at least once (including the keyboard). Why do these inaccessible fields exist? I am under the impression that they come about when trying to use old profiles with new versions of DCS that have new keybinds. Therefore, I assumed that a fresh install would prevent this - obviously not! Can anyone explain what is going on? Have I missed deleting a folder somewhere where the old profiles are kept, and they are now tainting the new profiles? Thanks.

As promised, here is an addendum to the original set of experiments. In these three subsequent experiments, the A-10C has taken an 'offset' and is approaching the SA-13 from an angle (as opposed to flying at it directly in Experiments 1-7). This is illustrated below: Results Experiment 8 - Offset - No countermeasures Slant range at launch: 2.1, 2.1, 2.2, 2.2, 2.2. Average slant range: 2.2. Experiment 9 - Offset - 3 flares / 0.5 s Slant range at launch: 2.1, 2.1, 2.1, 2.1, 2.1. Average slant range: 2.1. Experiment 10 - Offset - 3 flares / 0.5 s with throttles idle Slant range at launch: 2.1, 2.1, 2.1, 2.1, 2.1. Average slant range: 2.1. All 15 individual tests (in Tacview format) are provided in the zip file attached to this post. Thoughts Preemptive flare programs do not delay/deny SA-13 SAM launches in an offset scenario. It's interesting to note that the offset flightpath has increased the average slant range at launch by ~0.5 nmi as compared to a direct flight path. Perhaps this higher slant range is due to the higher heat signature of the exposed engines, as was suggested earlier in the thread. Another possibility is that the SAM AI must track a valid target for some minimum of time before it can launch, and therefore the lower rate of closure of the offset flightpath resulted in a higher slant range once this minimum time had elapsed (this is pure speculation on my part). :book: --- Crescendo_preemptive_flare_experiment_offset.zip

I might do some more preemptive flare testing later this week where I take an offset, rather than directly overflying the SA-13. Just out of interest.

I didn't comment on it, but it is strange. If you watch the Tacviews, the tests begin at 4.5 nmi slant range. The SAM itself 'activates' roughly 12 seconds later at ~3.4 nmi and starts tracking, but only fires at 1.6 nmi. I did pretty much the same tests back in 2012/2013, but that instance the average slant range at launch was 2.5 nmi. That's a 1 nmi difference between then and now, which I can't explain. That's a good point. Anecdotally, I've watched Tacview files where I've unknowingly overflown IR SHORAD in a fighter at speed. I was well within the threat bubble, yet it never fired. It could have been out of ammo, but if I had known the SAM was there and had been using a preemptive flare program, I could see myself thinking that it 'worked'.

eXPeRT, scoreboard pictures (:megalol:) and quotes like this… …don’t mean much when we’re trying to isolate variables in a controlled manner. It also shows a real lack of humility that does you a disservice if you want to convince people and be taken seriously. Posting a picture of your tracks folder to demonstrate your amount of experience, as if this proves that you must be right, is simply laughable! This is like a psychic advertising that they have spent a lifetime reading the palms of 10000 people. So what? It doesn’t prove anything. I could just as easily say that such experienced psychics are merely really good at fooling themselves. What about those homeopathy practitioners who treat people eight hours a day fives days a week? They and their patients swear it works, they have years of anecdotal experience, but simple physics shows it to be impossible. Yes, experience counts for something, but it never trumps controlled experimentation. The forces of the placebo effect, logical fallacies, confirmation bias, and other cognitive biases are limitless in their capacity to fool. We are all subject to these forces. It’s too easy to trust our human instincts and faculties, and leap to false opinions that we ‘swear are true’. What evidence, other than just asserting it to be true because you’re so experienced? That’s not evidence. You can point to all the tracks in your folder and all the hours you've flown, you can 'just know' that you're right, but ultimately it comes down to this: where's the data? If you're right, prove it. Show us tracks or Tacviews in a controlled environment that support your claims. This means isolating as many variables as possible, which means not using multiplayer, because this eliminates things such as lag, other aircraft 'stealing' a SAM's attention, script errors, bugs, or SAMs simply running out of missiles to shoot. My evidence, which everyone can download see for themselves, shows you're clearly wrong about preemptive flare use in general. I think you've conflated preemptive flare use with other tactics like using the Sun. Yes, you may be right about the Sun. So prove it. I am willing to be proven wrong, but I won't be convinced by your immodest bluster about experience and the how much more you play than all of us. Give me a break.

Time for some SCIENCE! --- Studying the effectiveness of preemptively using 'Delay/Deny' flare programs with the A-10C in DCS World 1.2.7 (lol - :smilewink: ) 1.0 Definitions “Delay/deny” – A flare program designed to be run preemptively (before any SAM launch), with the goal of delaying or denying a seeker lock and subsequent SAM launch. In other words, a delay/deny program attempts to prevent a SAM launch. "Flare density" - a measure of the number of flares and the rate at which they are dispensed. For example, dispensing 2 flares every 1 second has a higher flare density than dispensing 1 flare every 5 seconds. 2.0 Testing parameters DCS version: 1.2.7 Threat: 1 x SA-13 set to "expert" skill, oriented directly toward player aircraft. Player aircraft: 1 x A-10C flying at ~250KIAS, 7800t, straight and level directly over threat. Countermeasures: Delay/deny flare program started at 3.5 miles slant range to target, runs continuously thereafter. Care was taken to ensure the delay/deny flare program is running before the SAM activates and begins tracking. Flight is repeated five (5) times with various levels of countermeasures. Tacview measures slant range to the SA-13 at the exact moment of the SAM launch. Slant range at SAM launch is used as a crude measure of any delay in the launch due to flare employment. Experiments 1-6 were performed with the aircraft throttles set to military power. Experiment 7 was performed with the aircraft throttles set to idle before the SAM activated. 3.0 Results 3.1 Experiment 1 - No countermeasures with full throttle Slant range at launch: 1.6, 1.6, 1.6, 1.6, 1.6. Average slant range: 1.6. 3.2 Experiment 2 – 1 flare / 1 s Slant range at launch: 1.6, 1.6, 1.6, 1.6, 1.6. Average slant range: 1.6. 3.3 Experiment 3 – 2 flares / 1 s Slant range at launch: 1.7, 1.7, 1.6, 1.6, 1.7. Average slant range: 1.7. 3.4 Experiment 4 – 3 flares / 1 s Slant range at launch: 1.6, 1.6, 1.6, 1.6, 1.6. Average slant range: 1.6. 3.5 Experiment 5 – 4 flares / 0.75 s Slant range at launch: 1.6, 1.6, 1.7, 1.6, 1.6. Average slant range: 1.6. 3.5 Experiment 6 – 3 flares / 0.5 s Slant range at launch: 1.7, 1.7, 1.6, 1.7, 1.6. Average slant range: 1.7. 3.7 Experiment 7 – 3 flares / 0.5 s with throttles idle Slant range at launch: 1.6, 1.6, 1.6, 1.6, 1.6. Average slant range: 1.6. All 35 individual tests (in Tacview format) are provided in the zip file attached to this post. 4.0 Conclusions The data shows that the slant range of Experiments 2-7 was identical to the slant range of Experiment 1 (the control). Therefore, if we consider the slant range between the A-10C and SA-13 at the moment of SAM launch: 1. Preemptively employing a ‘delay/deny’ flare program has no effect. 2. Flare density has no effect. 3. Lowering throttles to idle has no effect. 5.0 Final thoughts The influence of the Sun in terms of delaying/denying SAM launches was not tested. Suffice to say, if the presence of the Sun does in fact delay/deny SAM launches, I think its effects simply overpower the worthless preemptive flares. In other words, I suspect that the Sun's delay/deny effects (if any) are separate and/or unassisted by flare use. That said, I might be wrong. Maybe delay/deny flare programs only work in presence of the Sun. I've spent enough time on this (:cry:), so perhaps someone else can test it (but please, don't just assert that it works). Crescendo_preemptive_flare_experiment.zip

Maverick-X, I stand by my post, but reading it again I do think it could be construed as coming on a little strong, to the point that I misrepresented you. I agree that the general concept is a good habit to get into, as long as people understand that its primary purpose (delay or deny) doesn't technically work in DCS (yet). I also agree that a preventative flare program can mitigate the 'reaction time delay factor' between the pilot/MWS detecting the launch and running the correct program. However, I still think it's absolutely worth highlighting the difference between a typical preventative flare program (goal: prevent or delay the launch), and a typical defensive flare program goal: (active defeat). To be fair to you, you acknowledged this. I agree that this is a grey area in which the distinction between the two programs is on a continuum, but I do think it's important that people start thinking about why and when to run preventative programs, defensive programs, or a hybrid of the two. My thinking is that a typical preventative program will save you from an unseen launch only some of the time, and when it does this is mostly good fortune. A preventative program is not as effective as a hybrid or defensive program (naturally), but of course the flare economy of the latter two programs will be worse. Really, I think the way people describe preventative flare programs, myself included, is ripe for confusion. Are we trying to prevent a SAM launch (goal: delay or deny seeker lock), or are we trying to prevent a launched SAM tracking our aircraft? I think most would say the former, but sometimes people mean one or the other, or otherwise conflate the two. So why not make this distinction explicit and rename the 'preventative flare' program? My suggestion is to instead call it a "delay/deny" program. If we do this, we now have at least three separate types of programs (delay/deny, defensive, hybrid). This is semantically much clearer, because logic tells us that any of these programs could be employed preemptively by the pilot in a 'preventative' capacity. The only difference between each program is its primary goal, it's effectiveness at meeting this goal, and its economy. So, sometimes the pilot may wish to be economical with flares and choose a delay/deny program only (and take the risk that an unseen SAM launch may kill him), sometimes he may use slightly more flares with a correspondingly higher chance of defeating an unseen SAM (hybrid), and sometimes he may be cautious and preemptively use many flares with a better chance of defeating an unseen SAM (defensive). Finally, I do disagree about the confusion issue. I have no hard evidence either way, but my feeling is that a not-insignificant number of people aren't aware that you can't prevent a launch currently. I say this because whenever this topic comes up (pretty regularly), you inevitably get a few posts talking about preventative flares, which is fine, but you don't usually see a nuanced discussion about the limitations of the concept in the current state of DCS simulation. Furthermore, you usually don't get a nuanced discussion about the goals and differences of delay-deny/hybrid/defensive programs and the why/how/when regarding their employment. You also get people who say prevention does work (eXPeRT for example), but this is contrary to controlled testing in my experience.

Well I'm happy to be proven wrong, but my testing says otherwise. I did the following test back in 2012/2013, and have run quick tests in all versions up to 1.2.6. The SAM behaviour has not deviated from these results in my testing experience, and I have seen no patch notes that would suggest that the issue has been fixed. Admittedly I have not done testing in 1.2.7. --- Testing parameters Threat: 1 x SA-13 set to "expert" skill, oriented directly toward player aircraft. Player aircraft: 1 x A-10C flying at 250KIAS, 9800ft, straight and level directly over threat. Countermeasures: Flare program started at 4.0 miles slant range to target, runs continously thereafter. Flight is repeated five (5) times with various levels of countermeasures. TGP measures slant range to the SA-13 at the exact moment of the SAM launch. This slant range is used as a crude measure of any delay in the launch due to flare employment. Results Test 1 - No countermeasures Slant range at launch: 2.6, 2.7, 2.6, 2.7, 2.5. Average slant range: 2.6. Test 2 - 2flares/2sec Slant range at launch: 2.5, 2.2, 2.5, 2.6, 2.6 Average slant range: 2.5. Test 3 - 1flare/1sec Slant range at launch: 2.6, 2.5, 2.5, 2.6, 2.6 Average slant range: 2.6. Test 4 - 3flares/1sec Slant range at launch: 2.3, 2.6, 2.5, 2.6, 2.6 Average slant range: 2.5. Test 5 - 4flares/0.5sec Slant range at launch: 1.8*, 2.6, 2.3, 2.6, 2.5, 2.4 Average slant range: 2.5. * I have no explanation for this aberrant result, and it has been excluded from the data set. Perhaps even an "expert" SAM operator occasionally falls asleep or forgets to press the right sequence of buttons! --- Those are my results in a simple single-player editor mission. I can't speak for MP, but I will say that there are important variables to consider there. Things such as other aircraft 'stealing' the attention of the SAM (so that it never launches at you) and the SAM itself simply running out of ammo. As for the sun, I consider that a confounding variable and chose not to test it -maybe it has an effect, I don't know. I know I was strident in saying that preventative flares never work, but I have not seen evidence to the contrary, specifically in a controlled environment (which is key). I welcome new evidence that falsifies my findings because that means we can learn something new.

As discussed, "preventative flares" is a complete and utter misnomer in the current version of DCS. I cannot be more clear about this. No SAM launch will ever be prevented or delayed by running a flare program in the current version of DCS! None, nada, zero! This is a deficiency of the current DCS SAM logic and it should be fixed. In real life, you should be able to delay some IR SAM launches some of the time by running a typical preventative flare program, but in DCS you cannot. No, they don't have an effect! I know I'm being pedantic about this, but this is exactly why people become confused about this topic. What you described is a missile defeat. Nothing was prevented, so we should not use the term "preventative". Now, it is true that occasionally a typical preventative flare program of, say, '1 flare every 1 second' (1F1s), may defeat an IR SAM after it has been launched, by this is simply a happy coincidence. Having flares out at a dangerous time certainly doesn't hurt, but most 'preventative flare' programs simply do not have the flare 'density' to reliably defeat a missile. Any missile defeat as a result of running a preventative flare program should be put down to good timing (due to tactics) and good luck and nothing more. Maverick-X, perhaps you may respond and say that your 'preventative flare' program is something more like 2F/1s or 1F/0.5s, in which case we are now moving away from prevention and more towards active defense. If this is the case, you would be better served by calling it a 'defensive flare' program. It is a subtle distinction but one worth making while the SAM logic remains unfixed. So, what is my point? 1. A preventative flare program and a defensive flare program are two different things. A preventative flare program is designed to delay a seeker lock and cause the SAM operator to hesitate, and should be relatively economical in terms of flare use. A defensive flare program is generally an 'all-out' program that uses a medium to high number of flares to actively defend against a SAM launch. A pilot may run the preventative flare program during generally vulnerable flight regimes, whereas the defensive flare program is run during the most dangerous part of the attack, or, alternatively, only when a SAM launch has actually occurred. 2. Preventative flares do not work in the current DCS version. Due to a limitation in the current SAM logic, you will never prevent an IR SAM launch no matter how many flares you dispense. Therefore, calling any flare program "preventative" in this version of DCS is a misnomer and semantically confusing. This issue should be fixed in new versions. 3. It's true, the general concept of preventative flares is a good one. In the real world preventative flares should delay some IR SAM launches some of the time. However, telling people to run preventative flare programs in DCS right now is telling them to do something that doesn't work. 4. If we do tell people to use 'preventative flare' programs, we should explicitly tell them that although the tactic doesn't work in the current DCS version, it may work in new DCS versions. I agree it's a good idea to get into the habit of doing it, but people must understand the subtle difference between real world tactics and tactics that actually work in the game. Right now, this talk of preventative flares is sort of like being being 'right for the wrong reasons'. 5. Until this issue is fixed, we should not think in terms of prevention, but in terms of pure defense. If we want to ensure the best chance of survival, we should run defensive flare programs in all vulnerable flight regimes (because prevention does not work). Neon67, my advice to you is the following: If possible, you should stay out of the IR SAM envelope entirely. This usually means flying high (15000 ft + AGL). Deny them the opportunity to shoot you. You should fly as fast as possible to ensure you have the energy to maneuver defensively when required. If in the A-10, you should be above 250 knots at all times (when practical), and even faster if possible. This usually means only carrying the absolute bare minimum of stores needed to complete the mission, i.e. no heavy/draggy load-outs — generally two mavericks and 2-4 bombs, that's it. If you're in the Su-25, same rules apply, but I would always keep it above 400 knots at a minimum. If you have to intentionally fly within the threat envelope of a potential IR SAM, you should be run a typical defensive flare program (2F/1s, 1F/0.5s, 2F/0.5s etc). For example, if you are diving to attack a target with guns or bombs, run a defensive flare program during the vulnerable portion of your attack. Yes, this means you will use lots of flares, and yes, you will sometimes run out prematurely. Nevertheless, this is the only way to give yourself the best chance to survive against an unseen IR SAM launch. If you run out of flares you should either carry more or RTB. In general, the concept of a preventative flare program (1F/1s etc) is a good one. You should be able to delay some launches some of the time by doing this. Therefore, if and when this issue is fixed, you should revisit this idea. Remember! A preventative flare program will always be necessarily worse than a pure defensive flare program. The idea is to be relatively economical with your flares and prevent the launch wherever possible, but then to go all out with defense when the launch actually happens. As stated, until seeker locks can be delayed or prevented, you should be more towards 'all out' with your flare use. If all else fails and you can see the SAM launch (and you can't turn and run), cut the throttle a little (lowers your engine temp), run your defensive flare program, and then maneuver to place the missile on your 3-9 line (your wing) and keep it there. Now pull some g while maintaining speed as best as possible and hope for the best. This only works if you stay FAST at all times and therefore have the energy to defend at a moment's notice.