Noctrach

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.

In principle I like this direction, but isn't it little bit too much wishful thinking? The problems I encounter using Jester revolve squarely around those aspects that you'd normally be talking about with your human RIO: target sorting in complex environments. Hence the focus on two items: Next target functionality Ability to "micro-manage" scan granularity. Imagine the following scenarios: Multiple bogeys but limited, scattered bandits. Multiple bandits of different type (two-ship MiG-31 at 50k for 50 but singleton F-5 at 40k for 30) Two-ship of solo F-14 pilots trying to sort any 2vX encounter. Jester would need a significant level of heuristic decisionmaking to correctly identify what's expected. In these cases there would not even be any other option than going STT and severely diminishing situational awareness. Hence, Next Target would solve all three of these. Managing this through narrowing the scan width and bars would at least help you isolate to make Jester's decision-making significantly less complex (and therefore less error-prone, as well as easier to implement?). I don't see this being fixed any other way, because not even a human RIO would be able to infer what do to in these situations without having a pre-briefed gameplan or some in-flight chatter. Conversely, once a human is briefed on the ROE and threat environment, these scenarios become extremely trivial. While I agree that the RIO drives the intercept and the pilot flies the intercept, Jester cannot be briefed on any situation that slightly deviates from the norm, so he'll need a little help from us.

Yeap, a lot of players also simply don't know how the backseater position works even in basic form. The act of interpreting a readout on the DDD (your main instrument) already contains enough intricacies to dedicate an entire machine learning project to. Capturing this in Jester is entirely unreasonable. At the end of the day, no matter how sophisticated he is, Jester isn't a RIO. He's a smart interface providing us access to a selection of backseat functionality. He's pretty good at that. However, right now he is unnecessarily increasing single pilot workload in combat. While I'd love to add a billion other elements to this enhancement request, the core of it is simply to provide quick access to the tools most critical for target discrimination in combat. In my mind there's only three things important to attain this goal: The ability to designate a TWS track for next launch Maximize control over radar elevation, azimuth and scan volume parameters Do the above with as few interactions as possible Even in this list I only consider TWS designation and antenna elevation to truly be problems that need to be solved for release. Anything else I'd consider a bonus.

"Sorry lads, the airborne invasion of our proud nation will proceed unopposed. We're all grounded due to an unfortunately dense cloud cover this afternoon." "But sir, we have TACAN and perfectly capable radars!" "Don't talk back to me Timmy. You know we only installed those as counterweight."