Hey, sorry another mod closed it. From reviewing your test footage it does appear to bite flares. But with this stuff we need replay files etc so we can review in sensor view.
Reason being is its very difficult to ascertain if the flare was in FOV without being able to see the FOV of the seeker which is much easier to see in sensor view. Gate width IRCCM doesn’t have a flare rejection capacity more over the reduced FOV makes it less likely a flare will enter the FOV of the missile, however if a flare does enter the FOV the missile is unlikely to reacquire the original target.
So simply; if we can’t see the FOV of the seeker we can’t make a judgement on if the flare was in FOV or not.
Its pretty evident that being able to consistently flare them at 1km away in rear aspect should not happen like it is shown in the video. Why can’t the devs themselves take 5 minutes to test it?
Feels like they expect the community to make a PowerPoint presentation of the issue and also provide the exact cause and code fix.
This is their job, not ours. I am not being paid, they are.
I meant the devs, not the moderators, the fact that they rely on the community and moderators to find and help to fix a lot of game issues is ridiculous.
If so, why is this issue not largely talked about? It’s been months since gatewidth missiles have been behaving like non IRCCM missiles. It’s a very apparent issue that affects many nations.
May I add to this, that from my experience AIM-9M are kinda unreliable lately as well.
I don’t have any definitive proof of course, but on average, for the last couple moths, they only sometimes actually work.
For example I have a couple screenshots here from a match yesterday. I was flying the Harrier GR7 and fired 3 AIM-9M at a F-104 in rear aspect. The Starfighter was in afterburner, flying straight and just dropped 4-6 flares for each missile and somehow that worked.
Am I crazy for saying that that doesn’t look right.
The screenshots are from the server replay btw
Suspension tracking IRCCM is easy to defeat from rear and front aspects, but hard from side (and top/bottom).
While gatewidth missiles are (should be) hard to defeat at short range, especially in a rear aspect. But in the past months, they have been performing like a slightly upgraded aim9L and nothing like they used to be.
Previously, they often would require pre-flaring to avoid a good IR lock at short ranges. Although it was possible to flare them even in rear aspects at short ranges with some jets and flare patterns. For example, inverted F-16 pitch with 0%throttle + a few flares then pitch up again.
Yeah I’ve been seeing relatively poor performance from gatewidth IRCCM at least when being shot at me. When employing suboptimal flare placement I could decoy Magic 2/R73 etc. at relatively short ranges that very likely would have killed me before the IRCCM got broken. On a side note, there have been some weird instances with seeker shutoff IRCCM that I have also experienced. From what I understand AAM-3/AIM-9M seeker sees flares-> shutoff + guides with IOG-> either reacquires target or loses target (then flies basically straight). In these rare instances the AAM-3 I fired either bit on and changed course for flares or had its IOG after shutoff completely fail (missile guided itself away from targets predicted path).
Funnily enough I’ve been seeing some crazy recent performances from AIM-9Ls doing some funky tracking (through flares) in front/side aspect that has definitely caught me off guard multiple times.
So I had a look and spotted some behaviour from the seeker post launch. It appears to on occasion pulse between NFoV and WFoV. I’ll have a chat with a Dev.
I noticed the same, but be sure to discard those instances where your flares get hidden by your own aircraft in relation to the missile.
For example, a frontal top down aim-9L against an F-16 that fires a single flare downwards has the chance to not even see the flares, especially at shorter ranges. Similar situations could happen if you are doing a horizontal turn pulling towards the missile and flaring below the fuselage.
Yeah that’s true though for most of the times when I caught an unexpected AIM-9L is during notches vs stuff like F/A-18s who throw everything at one plane. Just for laughs here’s a clip of me getting jumpscared by an AIM-9L successfully acquiring me 5km away after missing an F-2A.
IMO, this pretty much shows it is working properly. Yeah the ones at 1:52, and 3:35 both are a bit weird. But in every other shot it acts basically as you’d expect.
In the gameplay, you’re pulling into your flares, which is exactly what you should do. Given the rise time of large caliber flares, and the heat of Su-27 engines on non-AB, they only need a bit more than 0.4s of rise to decoy a flare. If you pull in front of the flare after that time, which you do, its gonna go for it.
Both of these are clear signs of server desync, and actually whats causing the flickering. However there’s something that’s not clear about it. There isn’t a strict order of consistency to this error. You would expect that the FoV would expand due to the missile not getting returns from its FoV, which in some cases, such as the used image is the case. However that’s not the case in all situations. As such, its likely that there is some inconsistency in the server replay past the actual inconsistency in what’s going on, as the server replay has been known to have issues with.
Additionally, why I think the flickering is largely an error with the replay, the seeker tends to very consistently snap back to the original target, even in situations where the flares often are hot enough, where if they were to actually be in the FoV, they would attract the seeker.
For instance, from the above image, the seeker goes back to the orignal target after roughly 0.8s, despite the fact that at the time, the flares are actually hot enough where if they were to be in the missiles FoV, as the replay showing it at full FoV would seem to say, the seeker would’ve prioritized them.
Further, the missile seeker still says it is tracking, and appears to be providing targetting updates on the original target, even while the seeker is not giving return signatures.
