Noctrach

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.

The mission briefing states a 4-5G break at 300-350 KIAS but I'm noticing to consistently hit 1.2 DME at the downwind it's much closer to 2.5-3G for an initial 380-400 KIAS. Much more like an F-16 300 KCAS overhead break if anyone is familiar with that. Even that feels like a pretty aggressive break with regards to how fast it slows the jet down and makes it hard to keep the turn level. Likewise extending speedbrakes after fully estabilishing the turn seems to make the transitions through 300, 250 and 225 KIAS much smoother. Is there such a thing as a "textbook" CASE I or is it really a matter of "what works for you so long as you fly within parameters and hit that beautiful 3 wire"?

I will say, I was initally quite shocked with how significantly the changes impacted the employment tactics of the AIM-54. Probably to the point of overreacting a bit. After experimetning more and trying the weapon in different situations I can conclude it's still a viable missile if employed in the right ways. It highlights the F-14's role as a medium-to-high altitude fighter-interceptor. You can still make absolutely unbelievable high-to-high shots that no other weapon in the game can reasonably replicate. Simultaneously, this makes it a bit more of a niche weapon now. It definitely isn't as reliable/safe anymore within AMRAAM WEZ for a large variety of reasons, though mostly guidance and AWG-9 related. Vipers, Hornets and Jeffs that manage to cross into 20 miles will (and should) be posing a very serious threat. It puts a much bigger burden on geometry and maintaining separation, making the jet less suited for lone wolf crews, much less solo pilots. This is much less due to AIM-54 performance and almost entirely on how easy it is for aware pilots to defeat the AWG-9 in TWS. Especially with Jester at the controls... I'll miss the old days, but it's probably a lot more realistic this way.

See, I also felt the F-14 seemed slow to accelerate in the transonic region, so I did a 1:1 test with DCS compared to the AAP-11 scenario below. Test parameters and method: Syria map, 15C, QNH 29.92. Stabilized level flight at FL35, IMN 0.70, engage full afterburner while maintaining level flight (verified altitude and level flight with info panel in transonic region to avoid instrument inaccuracies). Flare release to indicate IMN milestones for TacView analysis. (TacView shows TMN) Taking some error margin due to inaccuracies in manual testing and interpreting the graph lines, our F-14B isn't too far off in total timing accelerating from 0.9 to 1.20. However, this is mainly due to its overperformance in going from 0.7 to 1.0, after which it hits a wall of drag that takes over 50% more time to cross than per manual. It also accelerates significantly faster past IMN 1.60->1.65->1.69, taking a massive 3 minutes less total time to reach. Both ways it does seem like something that might be worth looking at. Maximum Afterburner - 66,000 lbs gross weight - 35,000 feet - ICO standard day AIM-9*2, AIM-7*2, AIM-54*2, 2*370 Gallon External Tanks, Gun+AMMO IMN DCS Time Mnl Time Delta DCS Dist Mnl Dist Delta 0.7 0 0 0 0 0 0 1.0 0:46 1:14 -0:28 6.6 10 -4.4 1.2 2:03 1:53 +0:10 20.3 17.5 +2.8 1.4 3:07 2:42 +0:25 34.1 28.7 +5.4 1.6 4:06 4:32 -0:26 48 56.3 -8.0 1.65 4:24 5:51 -1:27 53.2 74.9 -21.7 1.69 4:37 >7:30 -2:55 56.8 107 -50.2

The Mirage 2000, JF-17, F-14 and Viggen all notably demonstrate that it's entirely possible to go a bit further in complexity for a huge increase in fidelity. For this topic though, it's about consistency. If we simplify all DCS ECM as noise jamming, then it's odd that the F-16 radar can't see the same effect as all the other modules.

As per title, AMRAAMs fired in DTT SAM will always go for the same target. I couldn't find a topic on it so here's a bug report: Game version: Open Beta 2.7.11.22211 Reproduction rate: 100% Steps to reproduce: (Offline play) Lock two targets in DTT SAM, fire AMRAAM at first target, TMS right to step to secondary, fire second AMRAAM. Result: Both AMRAAMs impact the primary designated target. Expected result: Each AMRAAM to intercept its own designated target. DTT_AMRAAM.trk Tacview-20220422-153640-DCS.zip.acmi

Interestingly the first version ever released was also apparently conforming to the whitepaper but it had much better kinematics. But sure, when the guidance kinks are all worked out and we're not losing track anymore for no reason in STT or TWS it might become a passable anti-fighter weapon again.

The issue to me is that the C-AMRAAM can do the same shots (lazy cranking, late defending targets) you show in your tacviews at 40 miles, 33 kft, mach 0.8 with energy to spare. It can do the same thing pretty consistently at 35 miles 24kft, mach 1.1, while the AIM-54C can barely manage to go up against the 120B in similar scenarios, with the 120 being the better performer in a lot of cases. No matter the altitude, you're almost always better off firing an AMRAAM at pretty much any range inside 50 miles vs fighters. Where STT is concerned even the 27ER can reliably compete in the F-pole game on a well-flown Flanker due to its speed. The only thing the Phoenix has going for it right now is the battery life for those 70 mile bomber shots. Kinematically it's a pretty poor missile and the AWG-9 with all its issues keeping a lock isn't doing it any sort of favours. Once the 54's motor burns out it pretty much deploys the brake chute. I do hope this is not the final state, otherwise I guess in the end the naysayers were right about it being mostly unsuitable vs fighters?

Yeah it just makes no sense for this to happen, the AWG-9 will track the target perfectly through violent manoeuvring (provided it stays outside ZDF), including range and elevation on the TID and ATA on the DDD, but the DDD shows no return and the TID indicates trackhold/memory mode. As mentioned, the main issue is that it seems to force guidance behaviour like on a trackhold TWS target, i.e. pure pursuit to estimated location of target and then ARH-esque corrections as soon as it hits 10 miles. On evading targets below 25,000 ft this just means the missile kinematically self-defeats 9 out of 10 times.

The way to reproduce this is by adding a combined roll and antenna azimuth of more than 55-65 degrees. Its like the AWG-9 is simulating going out of gimbals without going out of gimbals So banking 30 while the antenna train angle is at 30 will always result in this effect. The easiest way to do it is by having a target in PD-STT at around 40-50 miles flying straight towards you and telling Iceman to bank 45 left or right.

Nah the loft angle doesn't really change, but if the track holds (no X) the mid-course guidance is smoother and it doesn't pull the weird hook turn it does at 10 nmi. It's weird though, the missile kinda guides even when track is lost, but it seems to guide in the same way phoenixes do when track is lost in TWS, it flies pure-pursuit-ish to a right-ish location and then does an aggressive correction turn if target is within front hemisphere inside ~10 miles. I haven't touched the F-14 (and subsequently, DCS) in forever though because I feel there's no point taking it into fleet air defence. Between the AIM-54s sub-20 mile range and the AWG-9's inability to hold tracks in both TWS and PD-STT it just doesn't have any teeth. Is this the intended performance of the Phoenix/AWG-9 or are we still in some interim purgatory waiting for the new API to finish?

Does it look like this? Because that's a bug I first reported slightly over a year ago now, which is definitely still in the game. @Naquaii would there be any indication on where this is on the priority list? It throws off guidance on PD-STT shots entirely making it impossible to F-pole with the Tomcat. AIM-54 shot in PD-STT with this behaviour are utterly anemic, 36 miles head-on shot at 1.1 mach 24,000 ft and they're below Mach 1.5 after only 55 seconds of flight flying a straight ballistic profile... (they don't guide because of this bug). That's not even covering 20 miles on a high closure target... Tacview attached Tacview-20220420-191636-DCS.zip.acmi

Gonna bump this up since there's a trackfile and multiple sets of evidence attached but thread status has not been updated yet Official documentation and pretty much all online video evidence support the FCR being primary sensor for HUD window 10 if target is locked for both NAV and A2A master modes, yet in-game behaviour is still different as of latest open-beta release. Any info on the team's stance for this item? @NineLine

Or @NineLine, whomever would be able to respond to or tag this thread

@BIGNEWY Would it be possible to get an ED indication on whether or not this is in the cards? It seems to be a very minor fix with huge QoL impact for those of us without FSSB joysticks. We're not asking for a rework of the internal response curves, merely an option to remove the breakout force deadzone, similarly to what exists in the helicopter module settings for the different trimmer modes. This would make the Viper much more responsive to fly for the vast majority of us that uses a traditional joystick, where breakout force is already covered by mechanical spring force. This also makes the module much more compatible with extended stick setups.

Notch sizes are probably not very public domain kind of information. HB modeled the AWG-9 with ±133 knots based on their documentation, so I trust that is correct. I doubt it's possible to get such objective data on how effective notching is for the modern radar systems on the F-16, F/A-18, JF-17 and AIM-54/120s. That said, in order to reliably filter out e.g. highway traffic with a mechanical array, you're probably always gonna be sitting at something like a ±60 knots filter for search modes. However, for STT modes I'd assume modern radars have a number of ways to filter and bias based on range, angular velocity, signature etc. to reduce this quite significantly. On top of that I think the main DCSism is how permanent and instantaneous a notch tends to have effect on missile guidance or radar locks. Radar memory esque features just don't work very well in DCS multiplayer, leading to short beaming manoeuvres often completely breaking lock with no chance of reacquisition. Add to that the fact that: chaff works as a chance-based radar flare for missiles for its entire particle lifetime resolving a radar contact for most modules is just a set of rules resulting in TRUE/FALSE for each given game object these rules themselves are very simplified, e.g. it doesn't matter if the target is at 40,000 or 40 feet, only "target below horizon TRUE/FALSE" and you can be damn sure there's plenty DCSisms at play. To an extent this is unavoidable without CPU-choking levels of simulation, but it's also just a large amount of LUA engine legacy. I'm sure they'll get around to creating a more rich simulation someday, but until then these are the game rules.

Yep, AI countermeasures is a universal LUA script somewhere in the game files. That's why they all have CM even if they "don't have CM" and all eject at the same rate, angle, quantity, etc. JustDCSThings™

From the block 50CJ manual: Window 10 (slant range) should indicate slant range from the highest priority tracking sensor. This is the FCR (in any mode) whenever an air contact is locked.The current DCS mnemonic (Bxxx) being present even if target is locked in NAV is incorrect, as this would treat the steerpoint/barometric elevation as the highest priority sensor even if FCR is SOI. I can send you the excerpt in PM if needed, but I'm pretty sure you guys have this doc. There's multiple HUD tapes on youtube with different blocks and tapes, all with identical behaviour to the description in the manual. This is not a "wishlist request" but a bug/incorrect/WIP implementation. OP's video is a Block 40 with CCIP or later upgrade (JHMCS) F-16N block 30, tape unknown, NAV mode with target locked showing locator line and radar range. There's multiple F-16D fam flights like this, block and tape unknown, HUD in NAV, showing both locator line and radar ranging with bugged target.

Thanks for the replies, but I feel people are putting primary focus on the least important (nice to have) bit of the request. I dont mind non-linear curves if that represents the real jet better. My primary request is the option to disable the internal deadzone, as you cannot currently personalize this for your hardware. (You can't apply "negative deadzone") This would allow people across the entire hardware spectrum to have an input setup that works for them. The current situation is rather detrimental to the experience for users with traditional joysticks. Especially so if those have an extension.

Not really, the only thing needed is the optional removal of the built-in deadzone. It does not affect the flight model in any way because there is no input sent to the FLCS inside this deadzone. This deadzone is the result of the breakout force needed for the real Viper to prevent unintentional inputs. It doesn't translate at all to traditional, movable sticks. If you were to have a 10cm extension on your joystick your first 2-ish cm of travel do not translate to any input. For all other flight models, the deadzone is 0 by default, so there is already an easy answer to make them work better with all sorts of flightsticks: Apply an input curve and deadzone to your liking. The problem is that this is something ED hardcoded internally, I'm asking an option to make this product to be compatible with the vast majority of hardware out there.

Is there any chance of ED giving the option to have an input curve without the simulated force sensing deadzones (breakout force) in the future? It would really make this module much more enjoyable to fly for those of us with traditional sticks. Ideally even a linear curve instead of the force sensing one. I get that you want to simulate the real jet but the effect on mainstream simulation hardware is very much the opposite, making a fighter with a reputation for being nimble and intuitive feel rather sluggish and "fly by vote".

Known, long-standing issue due to the original missile API for which it was implemented Once the Phoenix is moved to the AIM-120 API it'll be different.

The blinking happens 8 seconds before Ropt and that in itself isn't anywhere near Rtr. I believe it's defined as the distance that a lofted shot will intercept a head-on target with enough energy to do terminal manoeuvring. Note that this implies something like a high-G jink defence at terminal stage by an otherwise straight-flying target. Any manoeuvres prior to this point, or the target simply turning around and running will drastically lower Pk. In "the other sim" Ropt is something like 85% of the missiles maximum aerodynamic range. In all cases it's still a pretty low Pk shot on any aware, manoeuvring target. Considering the Phoenix can intercept non-manoeuvring targets at well over 70 miles, blinking at 50 miles seems very reasonable. If a launch doesn't activate the countdown on the AWG-9 and/or the missile doesn't track, either something was done to spoil the shot (loss of contact, too far off boresight, etc) or you have a bug you can report.