Noctrach

Yep :) that's exactly it

That does sound identical to what I'm describing actually. I might've not expressed this clearly but the PD-STT lock never "drops" as such. It just loses the contact return so guidance stop and the track goes into trackhold. When I said loses contact, what I mean is that in the DDD you will see the sweep stops getting a return. It still "treats it" like it's locked on, which makes it a bit pernicious since you won't even notice it's gone unless you're paying attention to the DDD. This is with default jets in singleplayer and multiplayer. Ground-start or air-start. No mods and no special set-ups. Jester or backseater. Always happens the same way. For the TWS issue: can it be that the TID starts mixing up tracks if one of them is lost? I see it happening often after the formation has already separated. E.g. two jets at about 30 miles that are far enough apart to be in separate resolution cells. One of the two does an aggressive jink that breaks track, the other continues flying and tracks normally. Phoenixes will behave as if they're both fired on the same track. Which of the two tracks they choose seems kinda random. (So sometimes they both guide on the good track, sometimes they both go stupid) I'm not comfortable turning it into a bug report though because I'm not sure what is happening exactly and whether it's intentional behaviour. It just seems rather odd.

Not gonna lie, I find this odd. I tested it again last Tuesday while I was piloting with a squadmate of mine in the back. He also saw the PD-STT contact disappearing consistently with the parameters I mentioned. Then again, the second part of your description looks very much like the issue I described. PD-STT, either with launching or without. Offset the antenna angle + roll the aircraft so that the combined sum of the two exceeds 55 and keep it there, you'll see the DDD contact fade out. TID treats it as lost track [X], missiles in the air stop guiding. Note that this does NOT happen in any of the TWS modes or with P-STT. Only PD-STT is affected, either from RWS or PD-SRCH. It happens both with MLC on and off, no other switch configurations. If there's anything I can do to help reproduce this I'd be happy to, as we have a 100% reproduction rate this way. The exact same result in both singleplayer and multiplayer. One thing that I did notice as a secondary issue when we were testing whether this happened in TWS as well. Sometimes when firing AIM-54 at a two-ship, if the TWS loses one track but maintains steady lock on the other, both Phoenixes in the air will guide as if tracks are lost. Which is to say, they will both stop steering and fly straight ahead until they go active or time out. (Which is standard behaviour we're observing for lost tracks, I think this is intended?) I don't know exactly when this occurs since it's happening only intermittently. No offense intended, but there's quite a lot of weirdness going on with the WCS right now and I don't know whether to fault the missile API or something in the AWG-9. The issue mentioned earlier in this thread is the only one I can reproduce with absolute certainty.

Lots of good chaff discussion in "the other thread" NineLine commented on Hoggit that they're reworking chaff currently https://old.reddit.com/r/hoggit/comments/mb9zp6/air_combat_sim_sim_podcast_interview_with_nineline/gs0c6wa/ Hold thine horses.

Ehhh, I don't mind the discussion as it turns up interesting info from various sources, but if it devolves into a "continuously bash Phoenix based on headcanon and poor notching skills" I'll ask HB to lock it down until they finish their investigation. Considering Victory205 was trained to employ the missile, while the rest of us have never even seen a real one, I'm generally inclined to take his insight over pretty much anyone else. Besides, taking into account the mere existence of clouds and hot summer days, I think an IR terminal seeker would've mostly been an operational downgrade.

@Naquaii In response to some of the questions, I know you're already checking so would you prefer to leave the STT issue in this (very interesting) thread or shall I crosspost it to the bugs forum?

I'm also going to hazard a guess that if you tally all the AIM-54A's launched online and compare to the actual kills, you'd reach a number that is significantly lower than 50% and rather much lower than the AIM-120B/C.

Multiplayer has a much lower tickrate than singleplayer. So the "diceroll" will be done less frequently, with the volume of chaff that AI spams this is a significant difference in the end result.

You have to realise the processing for a missile's radar array emitting a specific band of radiation is of an entirely different order of magnitude than having to process TWS resolution cells at long range. This is already true for the A-version. Provided the C-phoenix was capable of emitting in MPRF, which considering the time period is a very reasonable assumption, you're pitting short-ranged MPRF with digital processing against a long-range Hi/Lo PRF interleaved mode with analog filtering. That's not even a contest. AWG-9 was the first fighter-based TWS radar and used some pretty archaic stuff to realise it. However, its Pulse and PD performance was straight bonkers for the time period. This is why we get to the topic of P-STT/PD-STT as being the primary engagement method against fighters. In this mode, the AWG-9 is no longer the weakest link by any stretch of the imagination. The reason DCS players discount STT as a viable tactic is because there's an expectation that missiles always need to kill and that the only way of accomplishing this is to rely on the fact that most PvP pilots have no training, terrible SA and a whole lot of DCS-isms to contend with. So lobbing ARH in TWS at 40 miles or below is considered "the only option" since it's "silent". Add to that the utterly nonsensical approach to chaff-SARH interaction, the utter lack of other EWAR simulation, and the STT-like stability of TWS in some other modules and it's easy to understand where the misunderstandings come from.

Thanks :) I'm running the latest open beta

@NaquaiiDid some more testing today, I can conclude that the following is true: The AWG-9 loses PD-STT lock if the sum of your bank angle and ATA exceeds 55 So in level flight: Banking more than 55 degrees with a target directly on the nose (ATA ~0) will break the lock. Banking more than 25 degrees with a target at ATA 30 will also break the lock. Banking of any kind with a target at ATA 55 will ofc also break the lock. Any STT guided missile in the air is trashed because the track is considered broken the second the AWG-9 loses the lock. The AWG-9 will remain in trackhold for 2 minutes when this happens unless manually forced out of it. Reducing the sum to below 55 within 4 seconds will instantly regain the lock, resulting in two overlapping tracks (broken trackhold + new track from regained STT lock). This issue is reproducible 100% of the time. I understand we're dealing with old tech without a roll gimbal, but this math doesn't check out at all. Rolling in level flight should translate some of the azimuth onto the elevation gimbal, rather than the other way around.

I'm rolling away with the target at 0 and rolling back upright with the target held at 45. If you look in the DDD you see the gimbal limit stays under 50, which should be perfectly fine for a radar with a true limit of 65 degrees right? That's almost 20 degrees of play horizontally and over 40 degrees vertically... I've hooked targets much further towards the gimbal edges in RWS. The video link I attached shows it in action very clearly. I'll relink here https://streamable.com/76b19f Here is the same phenomenon, 25 degree offset, Iceman diving but no roll: https://streamable.com/87065u Targets were alive and flying straight and level, without chaff. It doesn't seem like it's hitting any sort of mechanical limit at all. Just the AWG-9 kinda... giving up?

@Naquaii Further question: Edit: Ignore some of my reasoning below, I was over-analysing The AWG-9 will start aggressively sweeping the antenna up or down if you are coupling roll with climb rates. Is this intented behaviour? Only descending -> No problem Only turning -> No problem Descending AND turning -> AWG-9 goes crazy and radically changes radar elevation It does not matter how smooth you do this, the second you couple a bank with a dive you lose lock due to behaviour described below. Edit2: This also happens if you don't couple them, bank first, dive second. Upon banking, the radar elevation will go from +1 degrees to -20 degrees. Rolling back upright sees the radar sweep back up from -20 to way past the target (> +10 degrees), losing the lock. It doesnt really matter if you do this abruptly or smoothly. Edit3: This also happens with a target flying perfectly straight and level It seems like the AWG-9 is coupling its antenna elevation with its antenna train angle in PD-STT when the aircraft rolls? Short video of it in action: https://streamable.com/76b19f When PD-STT on a target in head-on aspect, MLC switch set to either on or off, the AWG-9 will still consistently lose the target with below result. Target enters a 2G diving turn, Closure drops from 630 to 360 in about 8 seconds. The descent rate smoothly increases over this time from level flight to a peak of -22,800 ft/min. The AWG-9 responds to this by aggressively sweeping the antenna down to far below the target. It's not related to target, it's related to the F-14/AWG-9 itself Notice a -5.8 degree sweep, corresponding with a horizon-relative attitude of -21 degrees. The original attitude before we initiated the turn was about +16 degrees. Note that this is not a gimbal issue, the target is put on 45L, we are nowhere near the true antenna limits. The AWG-9 sweeps the antenna back up about 3 seconds later. Notice a sweep angle of +11.3 which corresponds to an angle relative to the horizon of -3 degrees. Due to lost lock and MLC-off, the radar will lock onto the first ground clutter it finds during its upwards sweep. The real target is currently elevated roughly 2 degrees above the horizon. With MLC on we see the same behaviour, only the AWG-9 will never stop sweeping back up. It actually gets a return hit at around +14 degrees, which is exactly the current target elevation relative to our aircraft attitude. However, it does not correlate this back to the original track and continues sweeping upwards until hitting radar limits. This seems like a genuine bug.

@BIGNEWY Has there been any statement on this? Chaff behaviour is bizarre for pretty much all missiles in the sim right now. Targets nowhere near the notch (60-70 degree offset), looking up at targets against clear sky. Missile still gets decoyed. I've seen missiles (both ARH and SARH) take 90 degree bat turns with over a mach of energy to spare, just to get to some chaff bundle almost a mile further back. If you're half-decent at notching it's not even funny how easy it is to get rid of them, a split second notch with a broadside of chaff is all that's required. It's not a matter of geometry, it's just about spamming enough of them. The 120C will do it a bit less than the 120B or the R-27, but it affects them all. All this in singleplayer, I can work on providing tracks if needed. Something is most certainly not right.

Honestly if you're nose hot within IR missile range any combat pilot worth his salt would be doing the same. IR launches are pretty easy to spot. I think this is more of an expectations problem because so many players in modern jets are heads down staring pointlessly at a radar or datalink page instead of eyes out for threats. Take a page from the AI on this one... it's called a heads up display for a reason :P

Really though, cranking/notching and chaffing upon a missile launch isnt a bug. I wouldn't dream of being nose-hot on any ARH platform inside 30 miles. Go to any organised PvP event and people will be doing much worse, much sooner. It's simplistic and immersion-breaking behaviour for sure. Luckily its also offset by the sheer brainlessness of their defensive manoeuvres. Shouldn't be hard to close the kill. I'd like to see the entirety of the AI massively overhauled but in terms of bugs there's bigger fish to fry in the near term. cough EWAR mechanics cough

@Naquaii Out of curiosity, it's not possible for you to simulate the effect on chaff on e.g. Pulse mode right? As far as my testing has indicated chaff and flares do not actually "exist" as much as they are simulated as subcomponents of the aircraft. Uncaged AIM-9's for instance do not see flares until they've locked onto the host aircraft. Neither can missiles see chaff/flares dropped by other hosts than the target they are currently intercepting. Would be pretty cool to be able to see when the lock is being spoofed.

I think what's a bit of a thingy is that in DCS the interaction of chaff/notches with STT is mostly nonsensical. Even for targets that aren't anywhere near the notch, or against an AWG-9 in look-up mode, more than 50% of AIM-54C's fired as SARH will go for chaff if the target drops enough. Considering PD-STT warns the target through the RWR, that's anywhere between 30 and 100 seconds of opportunity to do a jink, dump some chaff and call it a day. Smart use of MLC or proper geometry will not help this at all, since it's not the AWG-9 getting spoofed but the missile itself. What makes the AWG-9 seemingly stand out as such a poor platform in comparison to the modern ones is its very realistic radar modeling on one hand versus an incredibly simplistic countermeasure modeling in the sim. Though I would never ask for a change in the former, I'm hoping the latter becomes less of a pain as ED finishes the missile API in 2027. Just feels like a lack of agency when you're simultaneously dealing with the inherent weakness of the system (fun) and the weird RNG of the sim (not fun).

While I agree that there is a problem with the omniscience of AI, I do think it's important to bring some distinction. The AIM-54, and the AIM-54A in particular, is a huge smoky lamppost of doom. An aware pilot would 100% commit to defensive behaviours as soon as they see the telltale trail of the launched and lofting Phoenix. So I'd fully expect AI to behave this way within say... 30-40 miles. The key problem here is how incredibly binary the AI behaviours within DCS are. Different difficulty settings only adjust factors such as range, delay and inaccuracy. You can even read this back in the LUA files. An ACE AI will be able to level bomb with pinpoint accuracy in the F-5 at 30 knots crosswind, spot you immediately when you reach about 10 miles and respond instantaneously to every missile launch. A RECRUIT AI will have an inherent inaccuracy in an F-18 with perfect weather, take a couple seconds to spot you and respond slowly to threats. However, once the behaviour is initiated both will be absolutely perfectly aware of everything you do, even if you are in a blind spot. The second issue is the lack of sensor differentiation. A radar is a radar, an RWR is an RWR. An F-5 will have the same detection capabilities as a Su-27. A MiG-21 will have the same directional threat awareness as an F-16. I wouldn't expect this to change anytime soon, as it's not "bugged" per se. It's simply a result of 20-year-old AI code that's in very dire need of a complete overhaul.

Alright, it seems odd for it to be that easy to spoof. But fair is fair. It would seem this weakness would restrict the usage of the Phoenix to mostly STT against fighters, which would essentially turn it into a big FOX-1. That'd indeed mean the missile's capabilities would be quite severely limited by the platform. Thanks for the reply.

Feel free to move this to bug section if you want, but I'm curious if there's any sort of velocity gating implemented with the AWG-9. It is really very easy to generate broken TWS tracks that share no semblance to the original locked return. From the manual it seems relevant DDD information is missing for sure, so that's also why I wonder if it's implemented. Attached a track in the PG BVR instant action displaying this. The two-ship flight splitting up is guaranteed to break the tracks. In most cases, the original track will even be flying backwards, away from both new returns. If the system was really this poor at resolving separating contacts, firing on 2-ships flying less than a mile apart would basically be pointless beyond 30 miles. On top of that, the target doing a quick snake or barrel roll will almost definitely result in a broken track overlaid over the actual return, flying side by side. This happens even when MLC is disabled due to the altitude separation induced by my dive. (8000 ft at 23 miles is >3 degrees look-up) It should be getting returns just fine. The only likely explanation I can come up with is a poorly adjusted scan volume because it's trying to chase a broken track. I know trackfiles are broken/nondeterministic for the F-14, but I see the behaviour appear on replaying this one with absolute consistency so maybe it helps. Note that this track is recorded in single-player. The problem gets a thousand times worse in multiplayer when latency starts getting involved. While I fully understand broken tracks due to land-based clutter are a weakness of the real system. I find it hard to believe that this would be realistic behaviour for a system trusted to defend the fleet against cold war threats. BrokenTracks.trk

Man if you spent as much time flying as you did scouring this forum for things to get unreasonably upset about, your PvP kill ratio would be through the roof. Compared to the AIM-120, you can defend AIM-54 shots with your eyes closed if you know what you're doing in this game... At long range you do some quick jinks and the F-14 is guaranteed a broken TWS track. At short range, you stick to the ground, notch, drop some chaff and use the myriads of modern system advantages to eat the F-14 in the visual arena. Let's give all this a rest until the missile API matures a bit and multiplayer guidance behaviour stops being a loopy fiesta across the board every other patch.

Correct, but then again... Pulse is a lot more susceptible to EW. PESA/AESA is dark sorcery as far as most public sources are concerned. Neither are simulated well, if at all, within DCS.

The F-14 with its mid 60's radar had a lot of advantages in situations with heavy jamming that later radars would find almost impossible to solve. As someone put it, the power of the AWG-9 isn't the machine, but the fact that you have a human operator capable of judging and manually manipulating the raw input data. How do you teach an algorithm which reflection is a mountain peak, which is a speeding car and which is the low flying jet with the tiny radar cross-section? Modern radars have ways of solving this, but we're well into the early 90's before this starts becoming somewhat reliable. It simply requires a lot of processing power. Most of the SAMs in DCS are quite old. You also have to realise there's just a lot of "DCS-isms" going on around these kinds of topics. Part of this is due to the simplistic simulation of radar, part of this is the absence of genuine human intelligence, part of this is the absence of electronic warfare. Real life SAMs will not be constantly searching for targets. A known SAM location is vulnerable to SEAD/DEAD or can simply be avoided by pilots. The problems start when you get a SAM site going live right underneath you because it was networked in an IADS with the large search radars 50+ miles away. Now you don't know exactly where the missile is coming from and you are within lethal range so simple evasive manoeuvres won't save you anymore. That said, there's a great video of an F-16 over Baghdad evading six consecutive SAM shots. Again, human intelligence will find ways to mitigate the inherent weakness of the systems. This goes for both the pilots and the SAM operators.

The reality is that you cannot simply focus all the energy in a single spot. Even in locked mode the radar will still experience significant clutter from side-lobes. The "lock" means you have found a signal of interest that has a strong enough signal-to-noise ratio (SNR) to keep track of it. This mainly brings different factors into play like velocity and range gating to keep distinguishing this identified signal as the object moves through your line of sight. However, the more its radial velocity drops to near-zero, the more that SNR will start dropping, increasing the risk of losing the lock to clutter. Yeah I getcha, but the reality is that it's just the nature of the physics involved. I do recommend you give the youtube lectures a watch. It's good to see how astronomically large the effect of all the different sources of clutter is on all the other signals. Frankly, I think it's more that DCS makes it seem like getting a good lock is much more straightforward than it is in real life. Modern radars have less inherent noise, better materials, better electronics, higher frequencies, larger power output, better signal processing techniques... and they still struggle in a lot of ways. Only once AESA gets involved and you can listen to an entire spectrum of frequencies at once can you really say things change fundamentally. Yep, very true. A target overflying at high altitude is treated the same in DCS as a target flying treetop level, even though the complexity of detecting the latter is in an entirely different league. Yeah they'd filter in different ways but I presume the concept is much the same. It's all SNR in the end