Update: Added method for IR missiles seekers to react on flares - each modules handles separately? How and why?

[darkman222]

Update DCS 2.9.13.6818 shows:

-Added method for IR missiles seekers to react on flares before missile launch (from cockpit). Each module needs to add usage of this functionality separately.

And it shows ONLY for the F16, F18 and F5:
-Added AIM-9 seekers tracking flares prior to the missile being launched.

 

What this refers to is "pre-flaring" I guess, which is good to have it modelled. Why does it need to be activated "per module" Does it mean currently only F16, F18 and F5 have it activated?

But not the F14, F15 SE, F15. And also not the russian jets FOX2s? That will give the jets that have it activated just a disadvantage for sake of realism....

Or do I misunderstand the changelog?

[Vakarian]

This is a "common" misunderstanding I see people in DCS have. They assume because the physical thing behaves in a way, that things in DCS will do it automagically. Everything has to be coded. If someone doesn't code thing, it does not exist, period.

Another thing is, as far as I understand, what happens with things while they are attached to the aircraft are the aircraft developer's responsibility. When weapon gets launched, the game "removes" the weapon on the pylon and "adds in its place" a new weapon that is now active.

I'm 99.69% sure that is the reason why each developer has to add such things. They decide how their aircraft behaves, how its sensors react and interpret the data they receive and what data do they send to the environment. As far as weapons are concerned, as long as they are on the pylon, again I'm almost sure they are there purely for visuals. Only when they leave the pylon/rail/whatever they become active objects in the world. That would mean that before they get launched they don't see the flares as the missile "doesn't technically exist" yet. It starts existing only after it gets launched.

 

If I'm wrong in any of my assumptions, I'm more than welcome to be corrected. These are my conclusions from couple of years of reading this forum and few Discords related to DCS.

Edited February 19 by Vakarian

[darkman222]

And I believe that DCS starts to become a digital combat GAME soon, using exploits to win, if things that are introduced on one module are not carried over to every other module, splitting DCS into 3 sections of aircraft:

1. Flaming Cliffs Arcade modules

2. Modules in development, that dont get realistic features added as soon as its introduced on others

3. Modules that have realistic features added, giving them a disadvantage because other modules dont have that feature added, although it exists now in the DCS universe.

 

Your technical assumptions are correct, and logical. But it does not excuse DCS becoming a Frankenstein sim with different standards per module. This is only one obvious example.

Or let me better call it "DCS - per module - microcosmos", instead of DCS World.

Edited February 19 by darkman222

[Vakarian]

Well, since I've been in DCS (~2018), it's always been like this. Every module is a thing for itself. Whether that's good or bad is up for debate, but there never was a "standard". AFAIK there are minimums each module have to meet, but how far do they go in the weeds is up to the developer. Each upcoming module was trying to be better than one before, especially ones coming from 3rd parties. That in itself is not bad, but it does leave us with the inconsistencies. 

Now, if that's worth losing a mind over? IMO not really. This is a game first and foremost, a game which some take way too serious. 

[darkman222]

That depends on what standards one person has already seen. Son, I started in 1991 with combat flight simming. I have seen so many different simulators through out the years, up to 2018 when I started with DCS as well.

There were so many simulators with multiple controllable aircraft in one sim. And the RWR, missiles behavior, missiles notching, radar, radar jamming, countmeasures, heat signature behavior when engine spools down... they were all consistent in every particular sim I played.

Lets get back on topic and maybe we can discuss if MY assumptions are correct, that being susceptible to pre-flaring is (for now) only modelled in the ED modules: F16, F18, F5?

[Vakarian]

1 minute ago, darkman222 said:

Lets get back on topic and maybe we can discuss if MY assumptions are correct, that being susceptible to pre-flaring is (for now) only modelled in the ED modules: F16, F18, F5?

You are always welcome do do your own testing

[PawlaczGMD]

7 minutes ago, darkman222 said:

That depends on what standards one person has already seen. Son, I started in 1991 with combat flight simming. I have seen so many different simulators through out the years, up to 2018 when I started with DCS as well.

There were so many simulators with multiple controllable aircraft in one sim. And the RWR, missiles behavior, missiles notching, radar, radar jamming, countmeasures, heat signature behavior when engine spools down... they were all consistent in every particular sim I played.

Lets get back on topic and maybe we can discuss if MY assumptions are correct, that being susceptible to pre-flaring is (for now) only modelled in the ED modules: F16, F18, F5?

Based on my knowledge of DCS, you are correct. All other ED modules will likely be updated soon, and for 3rd party modules it is up to their devs to do it.

[SlipHavoc]

42 minutes ago, darkman222 said:

And I believe that DCS starts to become a digital combat GAME soon, using exploits to win, if things that are introduced on one module are not carried over to every other module, splitting DCS into 3 sections of aircraft:

1. Flaming Cliffs Arcade modules

2. Modules in development, that dont get realistic features added as soon as its introduced on others

3. Modules that have realistic features added, giving them a disadvantage because other modules dont have that feature added, although it exists now in the DCS universe.

 

Your technical assumptions are correct, and logical. But it does not excuse DCS becoming a Frankenstein sim with different standards per module. This is only one obvious example.

Or let me better call it "DCS - per module - microcosmos", instead of DCS World.

It was always a game, and always will be a game.  If you want full reality, the only option is to join your national air force.  As far as different coding for different modules goes, that's simply the way it is, it's not an "excuse".  In coding there's always a tradeoff (one of many such tradeoffs) between modularity and standards vs flexibility and specialization.  If you have a "standard IR missile tracking function" that is used by all the planes, then adding pre-flare tracking to that function would enable it in all the planes.  But that function would also have to have code that handles how IR tracking actually works in every plane, making it bloated and hard to maintain, and maybe slower, and if it has a bug then it affects all planes too.  Games of the past (I've been playing combat flight sims even longer than you) didn't have anything like the complexity in DCS, and didn't have third-party modules at all, let alone ones that are as or even more sophisticated than the first-party modules, so they never had to deal with problems like these.

[darkman222]

So a framework for "standard IR tracking" that every module, by every deveolper, for the same missile type to use would be a disadvantage? Yeah, if it had a bug, all modules would be affected. But its only one bug. For example the F16 and F18 often share the same bugs as they have been programmed by the same core team. Now you have probable two bugs that are related, but need separate fixes. Twice the work.

I am not a professional programmer, so I might be mistaken to think that.

But the past has shown that keeping consistency is not the thing that ED prioritizes. This is what bothers me here. Its a combat flight sim. Unfair and unrealistic advantages are gameplay relevant and people use them as exploits. In the end it harms DCS, the playing experience and us the community.

I dont care if non combat relevant systems in one jet are better modelled and worse in another jet. That does not matter in a simulated combat environment. Pre-flaring ( and all the other inconsistencies I mentioned) does for example.

DCS is comlex and huge. It was never built for what it has become now, I understand that for sure. But now that its why its even more important to keep priorities in consistency in game play relevant features.

Edited February 19 by darkman222

[SlipHavoc]

Just now, darkman222 said:

So a framework for "standard IR tracking" that every module, by every deveolper, to use would be a disadvantage? Yeah, if it had a bug, all modules would be affected. But its only one bug. For example the F16 and F18 often share the same bugs as they have been programmed by the same core team. Now you have probable two bugs that are related. Twice the work.

I am not a professional programmer, so I might be mistaken to think that.

But the past has shown that keeping consistency is not the thing that ED prioritizes. This is what bothers me here. Its a combat flight sim. Unfair and unrealistic advantages are a different thing because of gameplay.

I dont care if non combat relevant things in one jet are better modelled and worse in another jet. That does not matter in a simulated combat environment. Pre-flaring does.

DCS is comlex and huge. It was never built for what it has become now, I understand that for sure. But now that its why its even more important to keep consistency in game play relevant features.

Having a standard function has both advantages and disadvantages, that's why I said it's a tradeoff.  ED picked the option where there isn't a standard between planes, and that has its own advantages and disadvantages.  One disadvantage is what we see here: adding pre-flaring tracking behavior presumably requires modifying the function separately in each module.  However the advantage is that each module can have specialized behavior in that function that fits with its own avionics, and the function can be smaller and customized to that specific module.

As it turns out, I am a professional programmer.  I do mostly web development, but this exact same tradeoff appears all over the place, for instance in whether to use an existing framework or roll your own, use an ORM for database access or write your own custom queries, or to make web controls generic and reusable vs customized.  There is no universal right answer, and it seems there will always be someone looking over your shoulder and armchair criticizing...

IMO ED should not be optimizing for multiplayer competitive deathmatch anyway, so I don't really care if one module or another has some kind of "exploit" for a while that makes it unrealistically better or worse than it should be in Growling Sidewinder or SATAL.  Of course I would like it if the behavior is kept as consistent as possible across modules, because I do like realistic behavior, but I expect ED will do that, it's just going to take more time because of the tradeoffs they chose in this case.  And anyway, even if this behavior were perfectly consistent, there would still be "exploits" you can do in deathmatch servers, starting with the fact that your life isn't on the line, so you can take unrealistic risks.  You can also optimize the HOTAS controls to be much better than the real life planes, run in lower resolutions, sit in a comfy office chair instead of an ejection seat, and pull the paddle switch in the F-18, and many other unrealistic things.

[rob10]

ED has made it clear that it's added to F4, F16 and F18 to start and will come to other modules over time.  Is that perfect?  Maybe not, but it's not unreasonable.  It also gives them a chance to see how it's working in the wild and fix or tweak it.  I'd rather have it show up on those 3 planes than have to wait until they added to every plane in the game at once.  And I say that as someone who basically only flies the F18 so should be "disadvantaged" by this.

[SlipHavoc]

3 minutes ago, rob10 said:

ED has made it clear that it's added to F4, F16 and F18 to start and will come to other modules over time.  Is that perfect?  Maybe not, but it's not unreasonable.  It also gives them a chance to see how it's working in the wild and fix or tweak it.  I'd rather have it show up on those 3 planes than have to wait until they added to every plane in the game at once.  And I say that as someone who basically only flies the F18 so should be "disadvantaged" by this.

Come to think of it, is this actually going to be a disadvantage?  I haven't yet had time to play today after the patch, but my thinking is that this isn't going to change whether the missile is decoyed by pre-flaring, but rather that you'll actually be able to see it tracking the flares before you launch, so you can tell if it's locked onto the target or the flares.  Seems like that is going to be an advantage for the planes that have it enabled.  But in either case, it's just a visual indication, and pre-flaring works exactly as well as it always did.  I could be wrong about how this is going to work though, looking forward to trying it out.

[Northstar98]

2 hours ago, darkman222 said:

Why does it need to be activated "per module" Does it mean currently only F16, F18 and F5 have it activated?

Because the missile itself isn't modelled in any way before it is launched - it seems that it's up to the module to model any pre-launch behaviour.

This is why you not only see missiles locking flares only in the modules set up for it, but also why the Heatblur Phantom has different Sparrow limitations and functionality compared to other modules (such as the speed-gate tuning delay and being able to set the initial speed-gate for the Sparrow to home in on).

Personally, this should absolutely be changed. The only thing that should be up to the module is how they interact with it (for instance, selection, whether the HUD displays seeker look-angle, the state of a cool or preparation switch and how much cooling time remains etc).

This way:

• Developers don't have to duplicate efforts to propagate the same improvement to other modules. A knock-on effect is any future module will already be facilitated.
• Missiles have standardised behaviour, that depends on the missile (which is how it should be). No more rear-aspect only R-60Ms just because an L-39 fired it for instance.
• It would apply to AI missiles.

11 minutes ago, darkman222 said:

Lets get back on topic and maybe we can discuss if MY assumptions are correct, that being susceptible to pre-flaring is (for now) only modelled in the ED modules: F16, F18, F5?

All I can say right now, is when I use CA to test IR SAM systems (FIM-92C Stinger, MIM-72G Chaparral, 9M38 Igla), it's not possible to get the missile to track flares prior to launch - it's as if the flare doesn't exist meaning many of the consequences of pre-flaring isn't possible.

1 minute ago, SlipHavoc said:

But that function would also have to have code that handles how IR tracking actually works in every plane

Why exactly? How IR tracking works, specifically what an IR missile is able to detect (which, fundamentally, is what the problem is here), has absolutely nothing to do with the launch platform.

Some launch platforms are able to get the seeker look-angle and display it, some are able to command the seeker to look in a certain direction (i.e. slaving, SEAM etc) and aside from basic functions like enabling the seeker, caging/uncaging it, some are able to tell you whether a seeker has been cooled or not.

19 minutes ago, SlipHavoc said:

and if it has a bug then it affects all planes too

Even if it did, it would only need to be fixed once. Whereas now, the implementations are different so potentially different bugs affect different aircraft, which is more of a mess and less efficient, not to mention less realistic.

3 minutes ago, SlipHavoc said:

but my thinking is that this isn't going to change whether the missile is decoyed by pre-flaring

Nope, apart from aircraft where this function is implemented, flares don't exist to missiles before they're launched.

4 minutes ago, SlipHavoc said:

But in either case, it's just a visual indication, and pre-flaring works exactly as well as it always did.  I could be wrong about how this is going to work though, looking forward to trying it out.

No - this is incorrect.

It's not just a visual indication (this function applies to the Hind that produces no such indication)- because apart from these aircraft, pre-emptive flaring doesn't do anything, apart from potentially decoy a missile earlier after launch. To reiterate, apart from in these aircraft, flares don't exist to missiles before they are launched.

See this thread from just over half a year ago - Chizh acknowledges that missiles cannot lock flares before being launched:

[SlipHavoc]

7 minutes ago, Northstar98 said:

Because the missile itself isn't modelled in any way before it is launched - it seems that it's up to the module to model any pre-launch behaviour.

This is why you not only see missiles locking flares only in the modules set up for it, but also why the Heatblur Phantom has different Sparrow limitations and functionality compared to other modules (such as the speed-gate tuning delay and being able to set the initial speed-gate for the Sparrow to home in on).

Personally, this should absolutely be changed. The only thing that should be up to the module is how they interact with it (for instance, selection, whether the HUD displays seeker look-angle, the state of a cool or preparation switch and how much cooling time remains etc).

This way:

• Developers don't have to duplicate efforts to propagate the same improvement to other modules. A knock-on effect is any future module will already be facilitated.
• Missiles have standardised behaviour, that depends on the missile (which is how it should be). No more rear-aspect only R-60Ms just because an L-39 fired it for instance.
• It would apply to AI missiles.

All I can say right now, is when I use CA to test IR SAM systems (FIM-92C Stinger, MIM-72G Chaparral, 9M38 Igla), it's not possible to get the missile to track flares prior to launch - it's as if the flare doesn't exist meaning many of the consequences of pre-flaring isn't possible.

Why exactly? How IR tracking works, specifically what an IR missile is able to detect (which, fundamentally, is what the problem is here), has absolutely nothing to do with the launch platform.

Some launch platforms are able to get the seeker look-angle and display it, some are able to command the seeker to look in a certain direction (i.e. slaving, SEAM etc) and aside from basic functions like enabling the seeker, caging/uncaging it, some are able to tell you whether a seeker has been cooled or not.

Even if it did, it would only need to be fixed once. Whereas now, the implementations are different so potentially different bugs affect different aircraft, which is more of a mess and less efficient, not to mention less realistic.

Nope, apart from aircraft where this function is implemented, flares don't exist to missiles before they're launched.

No - this is incorrect.

It's not just a visual indication (this function applies to the Hind that produces no such indication)- because apart from these aircraft, pre-emptive flaring doesn't do anything, apart from potentially decoy a missile earlier after launch. To reiterate, apart from in these aircraft, flares don't exist to missiles before they are launched.

See this thread from just over half a year ago - Chizh acknowledges that missiles cannot lock flares before being launched:

What a missile is able to detect is up to the missile (or should be), but how it shows what it's detecting is up to the launch platform.  If you have code to support all the things that any launch platform can get from a missile, and all the things any launch platform can command the missile to do, it could be pretty clunky.  OTOH, one of the lessons I've learned from my years of programming is that you can never tell, looking at it from the outside, how much effort will be required to make any given change to a program; it depends entirely on implementation details that you cannot see until you're neck-deep in code.  So my saying that a standard function for this would be too clunky is also a guess, albeit informed by ED saying they have to implement it separately on each module.

I'll have to do some testing on my own to see what is tracked and what isn't, I can't tell what those videos are trying to show.  I'm not sure what the practical difference will be though.  Before, the F-18 for instance would show the missile locked on the target, but on launch, it would immediately go for the flares.  Now, it'll show it actually locking onto the flares, and you can hold off on launching until the other plane runs out, so that'll be an advantage.  I guess on the other hand, in a plane that can't cue the seeker to a radar target it might be a little more fiddly to get your lock back onto the enemy if the seeker starts tracking a flare, but if you're saying that any flares dropped before a missile launches are totally ignored, I'm definitely going to have to test that myself to verify, or see a video.

[Northstar98]

9 hours ago, SlipHavoc said:

What a missile is able to detect is up to the missile (or should be), but how it shows what it's detecting is up to the launch platform.  If you have code to support all the things that any launch platform can get from a missile, and all the things any launch platform can command the missile to do

Fortunately this list is rather small:

For showing what's being detected, all whatever this missile function would have to provide is:

• Relative seeker look-angle (i.e. the azimuth and elevation of the detected target from the perspective of the missile) - these missiles all use proportional navigation, which takes the relative bearing and elevation, differentiates it with respect to time to find the rate and then the control scheme acts to drive that rate down to 0. So, this variable should already be present.
• Seeker signal (which can be broken down to seeker sees nothing, seeker sees something but it isn't being tracked/isn't perfecly centred on seeker boresight, seeker tracking target/target perfectly centred on seeker boresight).

For control:

• Set seeker look angle (for instance, slaved to another sensor, or scanning a pattern) the module should provide whatever function that returns desired seeker look-angle.
• Cage/uncage seeker.
• Turn on/off seeker cooling.
• Enable/disable seeker.

Unless you can think of something I've missed, everything else is aircraft specific and not dependent on the missile itself (like which station is the missile located on, how much cooling time remains etc). Even in cases like the AIM-9X which provides a different tone when high off-boresight, you only need seeker look angle and a comparison to do this.

9 hours ago, SlipHavoc said:

I'm not sure what the practical difference will be though.

It means that:

• You may have to delay firing until there's enough separation between the target and the countermeasure. If for instance, you only briefly hold a good firing position, this could end up spoiling the opportunity.
• Some aircraft don't provide seeker look-angle to the pilot so in some cases they won't know if it's tracking a flare, leading to cases where missiles are potentially wasted because they weren't tracking the target to begin with. This is especially relevant to Cold War aircraft (like the F-4E, F-5E, MiG-21bis, Su-25/25T).
• Even in cases where aircraft do provide seeker look-angle to the pilot, there's the possibility that a flare steals the seeker's attention just before launch (potentially before a pilot can react to it), also wasting a missile.
• Minor one, but flares (including parachute flares) can be used as training tools.

I should also mention that this may apply to missiles with counter-countermeasure capability (the AIM-9M for instance suspends tracking if it detects a fast rise in energy, indicative of a pyrotechnic decoy

9 hours ago, SlipHavoc said:

but if you're saying that any flares dropped before a missile launches are totally ignored, I'm definitely going to have to test that myself to verify, or see a video.

Chizh certainly agrees.

So far I've tested with IR SAMs (they are the easiest to test) and this seems to be the case, in these tracks I can't get a tone on flares (let alone get the missile to track them) - only the aircraft launching them. These systems in DCS also inhibit firing until the missile is tracking a target. You can see that the only time I receive tone/tracking is when the aircraft is being detected/tracked.

If you are going to test, note that the Mi-24P also received this update according to BIGNEWY (and that one doesn't provide seeker look-angle to the pilot).

The only thing you gain by dropping flare preemptively, is that there's a chance that, as soon as the missile is launched, it has a flare in its FoV and can be decoyed slightly earlier.

Chaparral_NoPreLaunchFlareTracking.trk Stinger_NoPreLaunchFlareTracking.trk Strela-10_NoPreLaunchFlareTracking.trk

Edited February 20 by Northstar98

[SlipHavoc]

2 hours ago, Northstar98 said:

Fortunately this list is rather small:

For showing what's being detected, all whatever this missile function would have to provide is:

• Relative seeker look-angle (i.e. the azimuth and elevation of the detected target from the perspective of the missile) - these missiles all use proportional navigation, which takes the relative bearing and elevation, differentiates it with respect to time to find the rate and then the control scheme acts to drive that rate down to 0. So, this variable should already be present.
• Seeker signal (which can be broken down to seeker sees nothing, seeker sees something but it isn't being tracked/isn't perfecly centred on seeker boresight, seeker tracking target/target perfectly centred on seeker boresight).

For control:

• Set seeker look angle (for instance, slaved to another sensor, or scanning a pattern) the module should provide whatever function that returns desired seeker look-angle.
• Cage/uncage seeker.
• Turn on/off seeker cooling.
• Enable/disable seeker.

Unless you can think of something I've missed, everything else is aircraft specific and not dependent on the missile itself (like which station is the missile located on, how much cooling time remains etc). Even in cases like the AIM-9X which provides a different tone when high off-boresight, you only need seeker look angle and a comparison to do this.

It means that:

• You may have to delay firing until there's enough separation between the target and the countermeasure. If for instance, you only briefly hold a good firing position, this could end up spoiling the opportunity.
• Some aircraft don't provide seeker look-angle to the pilot so in some cases they won't know if it's tracking a flare, leading to cases where missiles are potentially wasted because they weren't tracking the target to begin with. This is especially relevant to Cold War aircraft (like the F-4E, F-5E, MiG-21bis, Su-25/25T).
• Even in cases where aircraft do provide seeker look-angle to the pilot, there's the possibility that a flare steals the seeker's attention just before launch (potentially before a pilot can react to it), also wasting a missile.
• Minor one, but flares (including parachute flares) can be used as training tools.

I should also mention that this may apply to missiles with counter-countermeasure capability (the AIM-9M for instance suspends tracking if it detects a fast rise in energy, indicative of a pyrotechnic decoy

Chizh certainly agrees.

So far I've tested with IR SAMs (they are the easiest to test) and this seems to be the case, in these tracks I can't get a tone on flares (let alone get the missile to track them) - only the aircraft launching them. These systems in DCS also inhibit firing until the missile is tracking a target. You can see that the only time I receive tone/tracking is when the the aircraft is being detected/tracked.

If you are going to test, note that the Mi-24P also received this update according to BIGNEWY (and that one doesn't provide seeker look-angle to the pilot).

The only thing you gain by dropping flare preemptively, is that there's a chance that, as soon as the missile is launched, it has a flare in its FoV and can be decoyed slightly earlier.

Chaparral_NoPreLaunchFlareTracking.trk 160.46 kB · 4 downloads Stinger_NoPreLaunchFlareTracking.trk 136.1 kB · 4 downloads Strela-10_NoPreLaunchFlareTracking.trk 172.3 kB · 3 downloads

Maybe it's only the SAMs then, because I just tested with AIM-9Ms and they track flares that are in the air before they're fired.  I used an F-15C, so it doesn't have the new tracking code.  I didn't get tone on the flares, but as soon as I fired it went straight for the flares that were in the air.

Anyway, from a practical standpoint, it seems like this new ability to see what the missile is actually tracking before it fires is mostly an advantage.  Previously if a target was pre-flaring you would just fire blind, hoping the lock it claimed to have on the target was really on the target, but now, you'll know, and you can adjust accordingly.

Now I wonder if IR missiles will track parachute flares, like illumination rockets.  And whether this is also a step on the road to getting IR missiles that can track ground targets...

As far as the coding goes, apparently you think it's simple, but what I'm saying is that you don't know whether it is or not, unless you're an ED programmer.  But the fact that it has to be implemented per module, and that it wasn't implemented for every module on this release, suggests to me that it's not as simple as you think.  Programming is funny like that.

[Weta43]

6 hours ago, darkman222 said:

And I believe that DCS starts to become a digital combat GAME soon, using exploits to win, if things that are introduced on one module are not carried over to every other module, splitting DCS into 3 sections of aircraft:

(...) Your technical assumptions are correct, and logical. But it does not excuse DCS becoming a Frankenstein sim with different standards per module. This is only one obvious example.

Or let me better call it "DCS - per module - microcosmos", instead of DCS World.

Game / SIM : təmeɪtoʊ / təmɑːtoʊ

...

So are you saying that E.D. should insist that the developers of all modules (ED included) should implement every new feature that any of the module developers implement & that no new modules can be released until all are at the same level of fidelity, or that going forward no-one should be allowed to release a module implement anything that isn't implemented in all the other modules ? 

Let's say someone implements a more 'realistic' approach to modelling radar cross section using their own database of aircraft and aspect - you're suggesting that they can't implement it until every developer's adopted for every one of their modules that has a radar ?

...& the developers of the approach should give this proprietary approach away for free ? ( & If not 'free', who decides what's a fair price - and could you not end up with perverse incentives to add novel capabilities just to harvest the fees from other developers or slow their releases ?)

What if most developers think it's an improvement, but one has nearly finished something similar via a different approach & don't want to pick up this implementation ? No-one can use either approach until a unanimous agreement about which one to use is made ?

I sort of understand your concerns, but really there's no solution short of not allowing external developers to develop for DCS that guarantees uniform implementation of onboard systems.

[Northstar98]

On 2/20/2025 at 3:22 AM, SlipHavoc said:

because I just tested with AIM-9Ms and they track flares that are in the air before they're fired.  I used an F-15C, so it doesn't have the new tracking code.  I didn't get tone on the flares, but as soon as I fired it went straight for the flares that were in the air.

Then it wasn't tracking the flares before it was fired. What happened is that the missile was launched with no lock, there was a flare in its field of view immediately upon launch and went for it. The flare still only exists to the missile after launch.

Which means, for aircraft without this new functionality:

• You've got the same chance of having your missile be decoyed by a pre-emptively released flare (if it's within the seeker's FoV upon launch) as you have for one released post-launch (though of course, the closer to the target the missile is, the faster a flare will leave its field of view, so there's still some advantage to pre-emptively flaring, but it's obviously dependent on geometry). Negating some of the advantages to pre-emptively flaring.
• It's not possible for flares to steal away a seeker's track prior to launch. Negating an advantage to pre-emptively flaring.
• For aircraft that don't provide seeker look angle (F-4E, F-5E, Mi-24P, MiG-29P, MiG-21bis, MiG-29/29G/29S (in boresight, though AFAIK, the only LOS they show for other modes is for radar or IRST, not missiles), Mirage F1, Su-25/25T and Su-27S/33 (ditto with the MiG-29) etc) if you have a tone, it's always on the target. It's not possible for you to accidentally be actually tracking a flare prior to launch (which could easily be the case in the F-4E or F-5E with an uncaged seeker), though the latter has received this update). Some of these aircraft (mainly the ones of Soviet origin), normally also inhibit launch unless the missile is tracking a target.

And this update applies to aircraft like the F-5E and Mi-24P (according to BIGNEWY) - these aircraft don't provide the pilot with seeker look angle and so don't tell the pilot what they're actually tracking, which should be further evidence that this isn't just a display behaviour change (not to mention Chizh's comments on the matter, he agrees that missiles do not track flares).

On 2/20/2025 at 3:22 AM, SlipHavoc said:

Anyway, from a practical standpoint, it seems like this new ability to see what the missile is actually tracking before it fires is mostly an advantage.

That isn't what the update is - the update is missiles tracking flares prior to launch, which is only the case for the listed aircraft. The F-5E and Mi-24P (which were also given this update) don't provide seeker look-angle in the first place. Before, if you had a tone it was always on the target, it wasn't possible for you to be tracking a flare without maybe realising it. If you launched and there was a flare in the missile's FoV, it falls to probability whether or not the missile will be decoyed.

Now it's possible for your missile to be tracking a flare prior to launch. In cases where seeker LOS isn't shown, you may not even realise the missile is tracking a flare (especially with uncaged seekers). There, this is absolutely not an advantage and makes pre-emptive flaring more of a valid tactic.

On 2/20/2025 at 3:22 AM, SlipHavoc said:

Previously if a target was pre-flaring you would just fire blind, hoping the lock it claimed to have on the target was really on the target

No, this was always the case, if you had a lock it was always on the target. Again, the flare doesn't exist to the missile before it's actually launched. The only thing that existed were valid targets (aircraft or cruise missiles, though I'm unsure if they would also track other missiles EDIT: they do, EDIT: somewhat ironically, parachute illumination flares are also valid) and the sun.

The missile can only be decoyed or otherwise track decoy flares post-launch. 

Of course, if upon launch there's already a flare in its FoV there's a chance for the missile to be decoyed by it (and if there's only a flare in it's FoV, it will obviously go for it, which is the case in your test as the F-15 allows you to fire missiles without a lock).

On 2/20/2025 at 3:22 AM, SlipHavoc said:

Now I wonder if IR missiles will track parachute flares

I actually stand corrected on this one, it didn't used to be the case. But they do so - what's funny however is that only modules that haven't received this new update will provide tone and tracking on illumination flares prior to launch. Every IR missile I've tested tracks flares post-launch, but only modules/systems that haven't received this new update will do so prior to launch.

Chaparral, Avenger, Strela-10, F-15C and Su-25 all produce tone and tracking on illumination flares prior to launch. The F-16C and F/A-18C however, only have missiles track illumination flares post-launch.

Not only is this evidence that prior-to-launch flare tracking could've been made global and not dependent on module (as it is for illumination flares, excluding aircraft that have received this update).But it also shows that the way DCS is set up is rather messy:

• Aircraft that have missiles produce tones of and track illumination flares prior to launch won't do so for decoy flares.
• Aircraft that have missiles produce tones of and track decoy flares prior to launch won't do so for illumination flares.

Of course, illumination flares are treated as weapons in DCS and decoy flares are not (in that sense they're more of actual entity). The same is true for chaff, which is why chaff doesn't exist for radars (even pulse radars) that use ED's radar model (which currently makes chaff for distraction and chaff corridors impossible, even against radars where this is applicable, such as the F-5E).

So if this change had instead made flares actual entities, we would've had our global, consistent change.

Also note, that in first F/A-18 track, despite the flare being centred in the missile's LOS on the HUD, it doesn't track (because the missile isn’t actually aligned with it) - proving that it isn't secretly tracking the illumination flare without telling you - it's only after launch that it's tracked (if it's in the missile seeker's FoV (which it is for my follow-up missile)). In the 2nd track, I establish a radar lock on the illumination flare, the seeker is apparently slaved to it and the missile still doesn't track it.

Another thing is in the newly uploaded Chaparral track you can see that the first missile actually gets seduced by the other illumination flare, potentially meaning they can be used as decoys.

EDIT: It wasn't in the changelog, but the F-4E produces a tone and tracks decoy flares prior to launch, it doesn't track parachute illumination flares, so it has also received this update (assuming it didn't do that before).

 

Chaparral_PreLaunchIllumFlareTracking.trk F-15C_PreLaunchIllumFlareTracking.trk F-16CM_NoPreLaunchIllumFlareTracking.trk F-18C_NoPreLaunchIllumFlareTracking1.trk F-18C_NoPreLaunchIllumFlareTracking2.trk Stinger_PreLaunchIllumFlareTracking.trk Strela-10_PreLaunchIllumFlareTracking.trk Su-25_PreLaunchIllumFlareTracking.trk

Edited February 27 by Northstar98
Grammar

[darkman222]

Thanks for detailed testing and sharing of your results and observations.

[darkman222]

Finally someone put out a video of it:

 

But shouldnt the seeker stay on the target as long as the missile is not uncaged but locked by FCR?

Bets are still to be taken how long it will stay the first iteration, and even how long it will take to be implemented on other modules. And the cirlcle will stay incomplete of course because I bet the FC3 aircraft will never get it.

[TheFreshPrince]

I think it's a great and realistic feature. But FC3 missiles then need to react to previously fired flares as well. If they do, it's kind of equal. No necessity to simulate lock-on problems as in the video above for FC3 planes.

But what I don't understand is: In the video you can see that the seeker can lock on to the aircraft over a distance easily, but it gets more and more difficult when the aircraft gets closer to the point that the seeker can't lock onto the aircraft anymore. Shouldn't it be the other way around? Shouldn't the seeker recognize the heat from the engine and be able to differentiate it from a flare? But in the distance it should be a furball to the seeker and create problems?

Edited February 22 by TheFreshPrince

[Xhonas]

23 hours ago, darkman222 said:

Finally someone put out a video of it:

 

But shouldnt the seeker stay on the target as long as the missile is not uncaged but locked by FCR?

No, flares should be able to decoy a missile even if it is in radar slaved mode. In the case of the Aim-9M tracking should be suspended for a brief time because of its irccm method (which is not modelled in dcs unfortunately). Another thing is that you still cannot decoy a missile in rear aspect by pre flaring, which is incorrect. 

[darkman222]

Feels like a half baked feature, that got its first iteration. The second iteration to follow "soon", then forgotten. And the F16, F18 F5 are stuck with an unfinished feature, that gives only them a disadvantage. Its a repeating pattern, I hope I am wrong in this case and the development does not slow down until a stand still...

[silverdevil]

@darkman222 this is mentioned in the recent patch change log. is this same thing that is discussed in this topic?

DCS 2.9.13.6818

DCS Core
Added method for IR missiles seekers to react on flares before missile launch (from cockpit). Each module needs to add usage of this functionality separately.

https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.13.6818/

[darkman222]

55 minutes ago, silverdevil said:

 this is mentioned in the recent patch change log. is this same thing that is discussed in this topic?

Yes. It states that is now implemented in the DCS core.

And for each module, in this case F16, F18 and F5 it says it in their own section, that the feature is enabled for that particular module. Thats why there are multiple mentions of it.