Noctrach

First and foremost, thanks for this insightful and open discussion. Highly appreciated and very educational. That said, from a much less brainy caveman perspective of a man with no degree of any sorts in radar physics, but with a huge passion for organized online play in DCS: I'm simply concerned with what is now well over 2 years of having the game's primary missile in flux on both the Stable and Open Beta branches. From the looks of this thread, DCS might well be simulating the most physically accurate missile seeker ever created. Yet as a player all I notice is that it still fails to capture a clear, transparent representation of how a missile should seemingly function. Simply put: Missile behaviour does not convey its mechanics to the player transparently, consistently or logically. This is not exclusive to the AIM-120, but SARH missiles are equally affected, if not worse. The simple fact is that there is no consistent way to tell from the virtual cockpit whether a missile is going to have a high probability of kill. Everyone flying frequently will be able to throw examples on the pile of missiles exhibiting weird behaviours causing them to miss. Whether from chaff they shouldn't be able to see, hard turns away from target on split-second notches, energy-draining intercept geometry or any other reasons that seem to defy intuitive logic. This could be hugely alleviated by a number of heavily abstracted, non-fidelitious solutions simulating aforementioned angle/range/magical fairy gates by simply narrowing down the notch width value making RWR's less accurate reworking chaff diceroll parameters (just shortening effective time per particle to 0.5-1 seconds instead of 6 would already go a huge way) giving STT/TWS locks an equal dice-roll chance to break lock as missiles currently do, while making the missile near-immune to chaff (Mirage 2000 approach) All of these could be implemented in a fraction of the time-span we've experienced now with the AIM-120 development. All of these would hugely improve clarity of "game systems" and the reflection of real world function and therefore enhance the immersive simulation experience for us players. While I hugely appreciate the mind-blowing depths you seem to go to for an accurate simulation, all that really counts at the end of the day is whether the simulation captures the essence of the real world, no matter how abstracted, as that is all players will ultimately experience. The way this thread is looking, I fear we're still years out from a satisfying, stable result on achieving this for the various core parts of this combat simulator.

You see exactly the same happen in the Sidra incident the OP mentiones. Its even debatable whether the fighters truly posed any threat. However, they were encroaching upon a carrier group and kept pointing nose despite the Tomcat group taking offsets, so were deemed enough threat to fire upon. For OP, if you see a 4-ship of known MiG-21s with possibly hostile intent but a restrictive ROE, I wouldn't ever wait to see if Im fires upon. Take a 55 degree offset and if they turn to intercept and the mission still somehow doesnt give weapons clear, I'd bug the hell out before entering WEZ. Let SAM take care of this until HQ has sorted its shenanigans...

While I appreciate that a significant amount of effort has to go into new early access modules to keep the cash flow up, the gap between new and old modules is becoming increasingly obvious. There are plenty long-standing issues that would require minimal effort but would have a large impact in perceived quality of the module. Examples of such low-hanging fruit: L-39 cockpit reflections Mi-8MTV2 internal cockpit lighting F-5E canopy textures, ADI drift and RWR search filter Above issues were acknowledged 12+ months ago, but have not seen an update since. I think I'm not alone when I'd love to see a timeline of when you expect to have resources to apply such low effort but highly appreciated fixes?

One thing I would like to mention for future guidance reference is that currently look-down shots just have the phoenix doing a straight beeline to the target. There's some pros and cons to this... slightly faster flight path, slightly shallower angle (bit less notch-sensitive), but it also has to do a lot of energy-intensive correcting in the thick air. I'm not sure which is the favourable geometry tbh. Two shots with the same geometry (28k -> 1k mach 0.9, 20 miles) AIM-54C AIM-120C

This doesn't make a lot of intuitive sense to me because the mid-course guidance is given by the AWG-9 which bases it on a precalculated time to impact, not on missile's real speed. That's not to say that DCS doesn't use missile speed. Who knows... The other thing is that this would not lead to the missile doing a turn-to-target as its first action after coming off the rails. I totally expect some curvature like this to happen as the missile goes into active guidance, since it is trying to find an optimum between intercept and energy conversation. But if the target doesn't change aspect, the missile trajectory should be pretty much straight since it hasn't to deviate at all from the predicted parameters. Current guidance has the missile spoil its own collision intercept trajectory by turning nose-on after launch and then compensating all the way to impact.

Thanks @IronMike I feel that matches the observations since yesterday to a T.

This is different tbh. The issue Whiskey11 describes is that the Phoenix goes pure-ish pursuit off the rail rather than flying an intercept curve. The effect of this is that it will waste a lot of energy constantly correcting for changing target aspect. It also means centering the T on a cranking target is pointless, because the missile will steer to turn towards the target rather than flying straight to predicted intercept point. So a shot with a properly centered T will have less energy due to having the missile correct heading during the initial launch phase. You're essentially shooting off boresight... What you saw on my images is just ED's fucked up interpretation of how a last second notch affects guidance. Possibly even a chaff interaction where it tries to do a 180 to get chaff that was released behind the missile when it no longer has the energy to do so. Not a Heatblur problem.

I'm positively sure I've seen missiles track to some extent on an extrapolated track, at least in the sense that they completed their loft in the direction of the track. Possibly in the way you mention where trackholds and real target are "close enough" but I could be misremembering. I don't recall them really doing what they're doing now. That said, most of the extrapolated tracks today were literally overlaid on top of the real returns all the way until TTI -5 so if the sim works as you say there's no reason why these missiles didn't track or go active. But yeah, the 120 does not inspire confidence right now

The issue to me is not that the extrapolated tracks don't activate, but they don't guide at all. They start their loft (or not at all) and just fly straight until stalling. This is a behaviour that was fixed in the past. For the other part, I've seen extrapolated track start flashing (active) while it was the solid track's missile going active. I've seen it start flashing way late or way early (I think again because it might have been tracking the wrong missile). It's hard to verify but in general I feel the guidances sometimes mix up when there's a broken track. I'll see if I can provide some tracks in the coming days. I'll add some tacviews for tracks where either one or both tracks broke. You'll notice one missile guiding and the other just flying straight. Tacview-20220608-173533-DCS-F-14B_IA_PG_BVR.zip.acmi Tacview-20220608-174918-DCS-F-14B_IA_PG_BVR.zip.acmi Tacview-20220608-181053-DCS.zip.acmi Tacview-20220608-181843-DCS.zip.acmi Tacview-20220608-182147-DCS.zip.acmi

Overall a step in the right direction I think. However, the loft seems less optimal now and I'm seeing quite a bit of guidance + AWG-9 weirdness involving broken tracks. Extrapolated shots don't guide at all and AWG-9 symbology seems inconsistent.

Change in drag is very minor, but welcome. Intercept geometry seems a bit better. The bad news is that this patch seems to have completely broken guidance with extrapolated tracks on the AWG-9 Extrapolated tracks don't go active. Presence of extrapolated track seems to break guidance, not entirely in a consistent way, sometimes it seems to affect other shots but this might just symbology related. Symbology for missile activation inconsistent, doesn't correspond with terminal phase, sometimes doesn't appear at all, sometimes appears for the wrong track. (This makes isolating the issue rather difficult, it's hard to assess what's really happening) Edit: Can unfortunately consistently reproduce this behaviour in Persian Gulf BVR instant action Edit2: Removing some elements TBD because the symbology issues make it hard to correlate tacview and cockpit

I think this hits the nail on the head for a lot of Phoenix discussions. Contemporary threats for the Phoenix would've been anything from heaters and short range SARH threats in the early days, to R-27ER in its last decade. Threats and defences have changed massively since the 80s. The fact it can still compete with the 120C (a missile that went into service nearly 3 decades later) under certain parameters, is crazy enough. Employ at parameters that match the threat you're fighting. Don't drive inside 40 miles against a high altitude AMRAAM platform, but likewise don't risk wasting your Phoenixes on daytime WVR fighters by launching at 60. I'm anxiously waiting to see what the guidance tweaks will do for terminal energy loss rates, but most of the shots I see are also just... "ambitious"

If "split-S when RWR starts bitching" is now considered an advanced missile defense then I don't wish to imagine the noise if the AI ever starts to employ sensible BVR tactics. e.g. taking an offset, or a pre-emptive notch as part of their timeline, setting up a grinder, pincer, altitude/azimuth split, etc. The AI is a step in the right direction, but there's so many more creative ways to spoil your BVR shots...

I recently picked up the Mi-8 but I'm wondering what the status is with the lights right now? In less-than-sunny conditions the instruments are extremely hard to read and the backlights don't seem to change this at all. At night the instruments are readable but the entire rest of the cockpit is pitch black even with the dome lights on (they really only illuminate about 30cm of the roof First image daytime in the rain with console lights maxed out, second nighttime with console lights maxed and red dome light on Is this still "in the works"?

I think it's a perhaps a tiny bit of the former but mostly the latter. If I would speculate anything it's that maybe the missile body might be contributing slightly too little to lift, putting more work (and thereby drag) on the control surfaces, but that's pure conjecture from my side. I think it's mostly related to sub-optimal loft geometry and poor terminal guidance. If we look at the current AMRAAMs (which might be a bit a bit lacking on the induced drag), their loft generally takes them higher than the Phoenix. Though the AIM-120 is also currently quite incapable of manoeuvring with targets at higher altitudes, either due to lack of control surface authority or just really bad geometry. It just doesn't do enough turning. The Phoenix on the other hand does way too much turning. I'm very much with you in that frustration. No matter the parameters, they will manage to bleed off more than a mach of energy in the last 7 miles almost every single time. I see a significant discrepancy in terminal velocity of STT vs TWS shots for the AIM-54, with the latter bleeding off speed much more rapidly by aggressively compensating for any target vector change. But I believe reading that a patch for this is slated for next open beta release, so we'll see if that improves things

Both straight line and loft. You can also simulate most of the testing scenarios mentioned on current patch with greater reliability than they could at the time (guidance has definitely improved even if it's nowhere near done). Can't quite get the AI to stay at 52,000 or M1.55 to replicate the 110 mile shot, but I managed to do a 105 nmi PD-STT launch at M1.55 42,000 ft vs a M1.45 Tu-160 at 46,000 ft with the AIM-54C: Missile was still going M2.63 upon impact after slightly over 70 miles of flight. For these conditions the AWG-9 is more of a limitation than the missile

One small correction, the 54C has the Mk47 mod 1 versus the 54A Mk47 mod 0, it's a slightly different motor with different fuel. It's also heavier than the 54A. I did just type a wall of text argueing that the 54C should be slightly faster than the 54A in straight line shots. But honestly the difference in thrust to weight is only 1.1%. Considering they have the exact same body but the weight difference shows a 4% advantage to the 54A, it would make a lot of sense that the 54C loses a little bit more energy due to drag over the wing surfaces. So in hindsight it's probably correct. Without significant differences in seeker and guidance performance the 54C Mk47 is indeed the worst missile in the bunch from a simply kinematic perspective.

I think this is a challenging argument to make when all the real world test shots and Heatblur's own CFD whitepaper correlate with the current kinematic profile of the missile in the sim. Could it be a little conservative in a couple areas? Sure, HB themselves have said this. But it really was overperforming significantly before the change. To me this thread should be renamed "Phoenix DLZ does not match missile kinematics" and we'd have a very different, very constructive discussion.

The AIM-54Cmk47 in the sim can cover about 70 (ground) miles when launched at M1.4+ before running out of energy (sub-sonic), so that seems pretty damn close. Limiting factor for 110nmi shots seems to be radar more than missile.

Thank you for attaching tracks to your post. I hate to say it but all of your shots are simply out of parameters. It's unfortunate that DLZ's in DCS seem to be somewhat inaccurate for most modules, as they are quite important in communicating expectations to the player before taking the shot. That said, for all AIM-54C shot above, the DLZ indicator does show your shot being very unfavourable, even if the symbology doesn't truly correspond to what's in the manual. (Ropt on the TID seems to equal Raero for the missile) All of your tracks show you firing subsonic (<M0.8) shots at below 40,000 (you lose a lot of altitude by not controlling the nose in the first 10-15 seconds of flight) at ranges simply exceeding the max aerodynamic range for the Phoenix under those conditions. What's happening on these shots is really easy, your missile gets sent on the loft geometry that corresponds to the range you're launching at, but you do not give it the energy to be capable of executing this geometry. If I retry the same scenarios but launch at 40,000 ft, M1.2 (similar to the reference shots exceeding 70 miles) my missiles hit absolutely fine after about 180 seconds of flight. Provided I fire them at the correct range. This Phoenix went to space This Phoenix hit the target Track for above shots is attached. Your tracks showed the dot at the end of the velocity vector indicating your target was out of range and your shot parameters were invalid. It seems to me the reason players see this behaviour happening more often with the AIM-54C than the AIM-54Amk47, which in return shows this more than the 54Amk60, is simply because the 54C is kinematically the worst missile in the bunch (@IronMike does it have the increased Isp at this point or is it still just a heavier 54A?). Quite frankly, people should stop expecting the Phoenix to be some magical physics defying death machine and learn how to employ the weapon. The reason folks managed to hit shots like this in the past is because the Phoenix was simply overperforming. It has since been fixed so will take some adjusting expectations. MoonPhoenix_and_HitPhoenix.trk

I'm saying that's a pretty big conclusion to draw from a hand-flown test compared to an unmarked line of an extrapolated aerodynamic limit in a manual. I'm also highly unsure if it's worth chasing HB through the difficult process of FM tweaking to fix the 1 in 1,000 fights won because someone got a gunshot off getting a handful of unrealistic angles by stalling the jet at 5000 feet above the deck. Especially knowing every FM tweak carries a risk of impacting much more common envelopes of flight. Even if the difference is numerically bigger than 5%, we're talking the absolute extremes of the flight envelope here. I don't think there's a single simulation jet out there that gets those right.

And what I mean by that is not that we should stop discussing the flight model in a critical way because this is an excellent thread. However, considering the HB devs have lives outside of DCS it's imo more pertinent to focus on areas where significant QoL improvements can be booked, like transonic drag, before we go into pointless minutiae at the edge of controllability. Any FM tweaks will have knock on effects regardless so one issue at a time. Just my 2c

But then you have to also take into account NATOPS charts are extrapolated test data and therefore not entirely accurate to real life performance either... from the video you screengrabbed it seems to me all of this is very much within the 5% margin of simulation error. This is fast approaching what the dutch call "geneuzel in de marge" i.e. putting way too much stress on unimportant details. Does it really matter whether it's -1200 or -1000 Ps if the end result is still going to be that you're wallowing at stall speed...

I feel a lot of these issues are people conflating DCS-isms with Phoenix modeling. Facts: Chaff modeling in DCS is far removed from realism. You can have an unbroken, MPRF STT on a modern pulse dopper radar and your missiles will still just follow a dice-roll on 6 second old chaff outside its seeker FOV for a target below the radar horizon. Netcode in DCS is poor, and the AWG-9 is quite sensitive to this so long range multiplayer engagements will have its share of jank Guidance modeling is too crude and will remain too crude for the near future to accurately simulate full missile behaviours such as range/velocity gating and optimised intercept geometry. The Phoenix, like all missiles, suffers from these sim-isms and will continue to do so until ED finishes the missile API. Even then some of this will remain present as an ED design choice or technical limitation for a sim environment. This is why its important for folks to bring tacviews to these discussions that show whether its a real bug or a DCSism causing their shot to miss. Otherwise we just degenerate into "phoenix is 100% broken" vs "works on my end". The Moon Mission Phoenixes might have to do with the AWG-9 + overlofting + netcode resulting in an impossible intercept solution at long ranges, but we'll need some data to look at if we want a constructive discussion here.

Im not sure what parameters you folks are firing with, but expecting consistent kills on fighters outside of 25 miles at 30k or below is just kinda pushing it. Thats already nearly 30% further than an amraam. If not for kinetics... then even just for the AWG-9 to be comfortably used against fighters. You have to imagine... 16 head-on TTI means about 11-12 seconds from registering the missile warning to actual impact. That is more than enough time to complete a split-S or sliceback, which will do the following: cash altitude for speed on the defending fighter drain energy on your phoenix to steer to new intercept course Increase the TTI through aspect change Your shot needs to have a solid energy advantage over the target when that manoeuvre ends to reliably complete that intercept. A high energy fighter will succeed in kinematically defeating a shot like that most of the time. Thats a kind of Rne expectation you can only put on something like a Meteor or 120D. As others have mentioned though, those long shots still give you a good tactical advantage. Now you have a running adversary which means its time to switch to STT and mercilessly run them down.