near_blind

I'm genuinely not sure what the track extrapolated symbol means in relation to STT in the Tomcat. In your video the DDD seems to lose the contact, but never loses the rate gates, and the TID shows target rate throughout, and the antenna is cued the entire time. I'm 95% sure the AWG-9 doesn't have any sort of radar memory capacity like TWS's track hold in STT, and it was my understanding that the TCS slave modes aren't fully implemented. What my experience has been over three years of complaining about Sparrows is that the track extrapolation symbol in STT appearing hasn't made an appreciable difference in how or if the missile tracks. Spending an hour or so running the BVR mission with the AI's Chaff response turned off seemed to confirm that: extrapolation symbol or no, the missiles guided to their targets. I tend to ignore it, but I've also reached out to see what it's meant to do. Tacview-20220420-180851-DCS-F-14B_IA_PG_BVR.zip.acmi Tacview-20220420-182056-DCS_stthit.zip.acmiTacview-20220420-184115-DCS.zip.acmi I really don't like this scenario because it starts the player too low and too close for a "proper" Phoenix engagement, but it does work, and you can absolutely get kills shooting outside of 20 miles in STT and TWS if you take prompt action. I feel like the common frustration since the January changes are that people spent 2.5 years getting used to the Phoenix acting as a kind of fast AMRAAM. The Phoenix isn't an AMRAAM, it can't be used in as broad an array as situations as an AMRAAM can. Trying to use it like that only exacerbates the weakness of the missile and leads to disappointment. It's your job as the pilot to get into a situation where the missile can perform.

The missile in that tacview looks like it both lofted and guided. Does the missile take a more aggressive loft if you don't crank?

Any radar is going to seem like it sucks if you haven't quite grasped how to use it yet. TID, track. You lock things in STT, you do not "lock" things in Track While Scan. I'm struggling to see exactly what's going on because VR resolution, but it looks like your target is below you. Jester uses RWS with an 8 bar scan. You transitioned to TWS, which by default operates on a 4 bar scan. You see the target in RWS because it's using a larger scan volume. You switch to TWS, which halves the vertical volume of your scan, and you lose contact because the target is now outside of your scan volume. Jester, in all of his wisdom, cannot actually STT a contact that doesn't exist on your radar. You see how the contact is a V instead of a ^ or a diamond? That means your radar never even saw this guy, and that contact is being provided over datalink to you from an external source. I'm going to guess for consistency's sake that the target is outside of the scan volume again.

https://gfycat.com/samesomberalbino-fury-road-tom-hardy-mad-max

I’m concerned we’re considering 50 miles to be long, and twenty miles to be medium ranged for the AIM-54. 20 miles is for Sparrows.

Things might change, you never know…

There should ultimately be different implementations between the AIM-54A and C, much less between them and the AMRAAM. You’re talking about three missiles spanning 40+ Years. Right now the A is missing a number of features that should make it less reliable and more temperamental. The C is missing features that should make it more capable.

AIM-54s fired from pulse should never loft. Pulse cannot generate guidance instructions for the missile, so the pre launch instructions are to go active and fly down the radars azimuth/elevation. As for guidance, the current implementation is transitional until a better one can ultimately be substituted

By "slew itself onto the target", do you mean before the target is within the scan zone, or before the track has fully built?

The AI's radar is slightly better than ours simply because it doesn't suffer from a number of the soft factors we have to deal with. To my knowledge the AI doesn't have to deal with the notch, range resolution, G limitations, etc. They are however using the same missile we do. If you didn't run into any issues where the track was extrapolated (had an X over the HAFU symbol), then there shouldn't be any real difference besides luck

Ran out of energy due to the relatively low altitude of the target Based on how the missile behaved and what the targets were doing when you shot, I'm going to guess the radar lost the target in a maneuver, the track went into extrapolation relatively soon after you fired and the missile never went active Missile is bled of energy by a combination of the target's low altitude and target maneuver Missile doesn't appear to go active, looks like a similar situation to shot #2. Phoenix is a thicc bird, it doesn't appreciate playing down in the soup all that much.

Without something like a tacview or video it’s hard to diagnose. If the missiles are all going active and timing out as expected, I can think of three options. You’re getting unlucky with your chaff dice rolls The Jeff’s are maneuvering such that they’re bleeding your missiles of speed to be point they can’t maneuver to intercept The you’re getting screwed by by guidance algorithm. (Missiles passing within 200 feet without exploding) options 1 & 3 have no solution besides faith and prayer. Option 2 can be ameliorated by shooting a bit closer

There are several threads discussing the Phoenixes

He can get confused, that’s why it’s generally best practice to wait Until he finishes each point before asking for another. In this case I believe the issue is jester is trying to input the altitude of a YY point in navgrid, and is instead putting it into own ship altitude.

So looking at that, I can guess one of two options. I think this is the more likely. Right now the missile is set to take an aggressive loft because the AIM-54 performs best when it is able to very high, reduce atmospheric drag, and then use its weight to fall back on to the enemy at high speed. It's bias towards lofting can encourage it to do that over other, more common sense things. Your missile took such an aggressive loft for reasons I'll get into, that it essentially went straight up, stalled, and then self destructed once it fell below a critical speed. Those MiG-29s are flying in close enough formation that the poor range cell resolution on the AWG-9 won't be able to clearly break them out for some time. At medium distance, the AWG-9 will begin to break out the single track into multiple tracks in a semi random manner. Because the radar can't reliably break the two contacts out, it will create numerous false tracks that will age out, possibly including the original "true" track. Shooting on one of these is always risky because it's a coin toss if the AWG-9 will disregard the track the missile is guiding to as "false", and thus trash the missile. I personally think this is an example of case #1. Your track on the TID doesn't appear to be extrapolated. Your engagement set up is also extremely unfavorable to the missile. You're subsonic, at 8,000 feet, shooting at a target that is also at 8,000 feet, at 60 miles. The Phoenix can comfortably make a 60 mile kill, but you want/need to be higher than 30,000 feet for the missile to retain enough energy for this to happen. To try and retain as much energy as possible, the missile is attempting to do a turbo loft, to such a degree it has broken the lofting algorithm and trashed the missile. This is a bug, it's not likely to be fixed until ED/HB determine a better lofting algorithm, or ED reach a point where they release the new missile API to third party devs. The AWG-9 runs the entire missile engagement on a set of predictions and assumptions it makes when you launch the missile. The TTI is an estimate of how long the missile will take to reach the target. Furthermore the missile has no way to communicate back to the radar, so the radar has no idea the missile self destructed. As far as the radar is concerned, the missile still has another 114 seconds where it needs guidance support.

Without a definitive record, hard to diagnose, but why not? The missile is over-lofting. This is a bug that was introduced with the new kinematics and loft settings where the algorithm that shapes the missile's trajectory does a dumb and the missile doesn't steer to target. In my experience the missile usually flies over the target by something like 30K feet and then tries to turn back around and chase the target. Indication for the pilot is that the TTI timer will be abnormally large, and won't tick down in a timely manner. There's no real fix for this other than don't manually loft the Phoenix, and pressure ED to give 3rd Parties access to the API. The AWG-9 took a dump, the target track has entered extrapolation/trackhold. The missile should be guiding to where the AWG-9 thinks the target track is, however a limitation of the legacy APi the missiles currently use mean that if the position the radar thinks the track is at (and thus the missile is guiding to) is larger than some arbitrary distance from where the target object actually is, the missile will never go active. Your cue as pilot is the extrapolation X over the track, and the fact the TTI will never flash. The missile was decoyed, and is flying to the former position of a chaff bundle well behind the target.

How are they missing? failure to track? not enough speed for terminal guidance? decoyed by CM? Got a tacview?

MLC was removed for PD-STT a patch or two ago, but the zero doppler filter still exists. If your target has less than +/-100 knots closure, the radar will still drop lock.

I get that, but usually an issue like this is caused by the AWG-9 thinking it is in a position that it isn't, and that is usually caused by the RIO or Jester messing up coordinate data input. In my case I had jester input each of the six non numbered waypoints in rapid succession, and I'm curious if the speed which he entered them affected the issue, or if a specific waypoint type affected the issue, or if it's something completely unrelated.

Are you having jester inputting waypoints, and if so which? I recently ran into this in SP And have been trying to think of a cause.

I’d need to check, but I believe as of a few patches ago he should enter elevation automatically

You may want airspeed on your HUD, but it's a moot point until something changes and the F-14B(U) or D magic themselves into existence. Luckily an intuitive, hyper granular airspeed indication device accurate down to a fraction of a knot exists for you to use: it's the big plane outside your window trailing a hose. If it's moving aft, you're going too fast, if it's moving forward, you're not going fast enough. I'm only being half flippant here. There's nothing in the cockpit that's going to be anywhere near as useful as watching the aircraft you're rejoining on. Knowing the air speed is an intermediary step, but it isn't a necessary one. it might have helped you with the A-10, but if getting hung up on not knowing it is impeding you in the F-14, you might want to adjust your approach so you don't rely on it. The way to do that, as other people have pointed out, is to practice flying formation with the tanker until you can intuitively match air speed with it visually, and feel comfortable such that you can position at any point around the tanker that you desire.

Did you perhaps put your weapon selector into SW or SP/PH?

He's trying to IFF/VID the target, and he doesn't have a VDI repeater.