Arctic Fox

Additionally, there's a separate but related issue: If the track is dropped and you manage to reacquire the target in MPRF quickly enough, the missile will also reacquire and resume guiding on the target. Regardless of what the radar's PRF selection logic should be here, the missile should not be able to guide on a target with the radar in MPRF rather than in a missile illumination compatible mode (IE PDI). AIM-7 MPRF Reacquisition.trk

When employing Sparrows, the radar automatically switches from its regular PRF selection to HPRF PDI on launch. Against a hot target this is perfectly fine, but when attempting to engage a rear-aspect target, the switch from MPRF to PDI seems to almost always cause an immediate loss of track, with the target going into memory. This means that attempting to shoot a Sparrow at anything but a head-on target with the Hornet is borderline impossible right now. There are a couple of problems here: A. The radar's ability to maintain a rear-aspect target in HPRF should not be binary. If the target is near zero closure and over heavy terrain clutter then a failure to transfer the track to HPRF makes sense, but if the target is heavily separated from zero doppler and over little clutter, such as at high altitude or over water, it should be possible to maintain the track in HPRF. B. From my understanding, with Sparrows selected the radar should continuously attempt to transfer the track to HPRF PDI even before a launch is commanded; this should provide some level of feedback on whether the missile should guide or not. It is also not currently possible to manually switch to PDI while in track, only in search. If the transfer to HPRF does fail then launch should probably be inhibited. Alternatively the target should continue to be extrapolated until manually commanded to stop (IIRC this is what should happen with any lost track with AIM-7 in flight, but I'm not completely sure), or FLOOD mode should be engaged. Either way the current behaviour where pressing the missile launch button just immediately breaks your track and trashes your shot does not make much sense. Tracks showing attempts to engage a Fitter and a Bear are attached. I did these tests over the ocean at relatively high closures which should have improved the probability of a successful track. AIM-7 Fitter.trk AIM-7 Bear.trk

I am also experiencing this. I manage to command IFF or NCTR once in a sortie and then it doesn't seem to work after that.

The unknown IFF square should not really show up at all in DCS, that seems to be correct right now.

Hoggit enabled script IC because it is now possible to enter servers that disable it with things like modified weapon files. It's completely ridiculous that the option to disable innocent things like countermeasure profiles is the same setting used to stop people from changing their weapons into thermonuclear bombs. We've had this drama before when ED extended IC to scripts in the first place, breaking all modifications to things like countermeasures and display export in MP. That was reverted but now we're back here again. It's really frustrating that what should be basic features to the game are only controllable by file modification and subject to these bizarrely ham-fisted attempts at anti-cheat.

An update on this: As of the current patch, the problem of NCTR print creating a wrong track classification when flying on REDFOR still seems to exist. Continuing issues with AIFF symbology and how its functionality is currently implemented in the F-16 I have outlined in the other thread on this subject here (which really should be in the bug reports rather than wish list forum).

The yellow square Mode 4 reply ED has implemented as a "negative" reply is described as an unknown reply, and publicly available manuals like the Greek and Chilean -34s state that they should not normally happen at all. IE normally the only reason such a reply would be produced is as a result of some fault in the transmission. It should not appear on any track that does not produce a reply like it does in Wags' video. I feel like ED has had some misunderstanding of the fundamental concepts of AIFF functionality in the F-16 at this point. In a previous video Wags talked about a negative IFF reply contributing to track classification, something which documents (for example M3) explicitly state is not a feature of the jet, and now it seems like we're getting symbology for radar targets that fail to reply to IFF (I am assuming ED doesn't think that hostile aircraft will actually send out a "negative" reply). In reality the manuals essentially paint AIFF functionality as largely disconnected from the fire control radar itself. AIFF interrogation can happen with the radar in A-G mode or even with the radar off, replies can come from undetected friendlies (but of course not hostiles, at least in Mode 4) and replies are explicitly not correlated with tracks to provide classification. It is essentially a separate system using the same display, and it's up to the pilot to correlate the information.

Looking back at my original message my wording wasn't super clear about that, so no worries.

I literally said that NO RAD while TMS Forward is held is correct, my concern was what happens after TMS Forward is released.

The problem is that the radar should remain slaved to the HMCS LOS until commanded to do otherwise, rather than revert to HUD boresight at the instant the TMS is released if it can't find a target. All publicly available manuals are clear on this. The Hornet works like that as well. And it just makes sense, especially if you consider that the helmet might be slightly misaligned which would make such instantenous function useless. If ED's M4.2+ documentation or SMEs say otherwise then I will be very surprised, but I can't challenge them. All I'm asking is that they double check they haven't missed anything, because I find it hard to believe it works like it's currently implemented in the game.

I'm not sure where you got this idea. The GBU-24 is specifically designed for long glide and low altitude loft employment where its different autopilot profiles can bring its seeker into view of the laser spot well after release. If you need a source, the Air War College document "Precision Guided Weapons Training and Employment" (available publicly on the DTIC archive here) outlines the different guidance profiles used by the autopilot in different release parameters (I believe these are now known "Mode 1" profiles, newer versions of the bomb have several modes that can be configured within the guidance unit). It makes it very clear that the bomb has mid-course and terminal guidance stages, with the latter activating on detection of the laser spot well after release. For example: GBU-24's proportional navigation capability means it can be employed without a delayed laser without worrying about energy losses, but I have never seen anything indicating it has to be.

The latest changes to the Viper's HMCS ACM acquisition function in today's OB patch are inconsistent with publicly available documentation on Viper helmet functionality (such as the MLU M3 handbook, for example): While the radar being commanded to slave to the helmet LOS and remaining silent as long as TMS Forward is held down is correct, the radar should explicitly remain slaved to the helmet LOS and continue to radiate until a target is acquired, a different mode is commanded or the LOS becomes invalid. The current behaviour in-game is that the radar will only attempt a HMCS acquisition at the moment TMS Forward is released, then revert to regular boresight acquisition immediately if a target is not acquired, which doesn't seem to make a lot of sense. The previous implementation of this feature seems to have been more in-line with what's described in the documentation.

When you have the newly added aircraft configuration panel up, normal simulation key inputs still appear to be registering in the background. For example, I have my numpad keys bound to the jet's UFC, so when I try to type in a laser code it also registers unintended UFC button inputs: a22.mp4 Not really a critical problem, but it could lead to accidents in some cases. On a somewhat related note: It doesn't look like there's a convenient way to input a single code for all bombs on the jet anymore. I think that could be a nice addition to the panel in the future.

Here you go. Upon further investigation it looks like the classification of the contact on NCTR is based on its coalition. While flying a blue F-16 and interrogating a red target, the contact showed up red. While flying a red F-16 and interrogating a blue target, the contact showed up green. While flying a red F-16 and interrogating a red target the contact showed up yellow, which I can only presume is the result of a conflicting "two factor" classification based on friendly IFF and "hostile" (red) NCTR print. AIFF response being correlated to track classification is in itself incorrect behaviour according to the MLU manuals. F-16 IFF Test - Red F-16 vs. Blue.trk F-16 IFF Test - Red F-16 vs. Red.trk F-16 IFF Test - Blue F-16 vs. Red.trk

The MiG-23 should in no way return a Mode 4 response to my interrogation. Let's imagine it has NATO IFF equipment built in (DCS currently abstracts this), it would not reply in Mode 4 to an incorrect interrogation relative to its own codes. It would stay quiet to not give away its position. EDIT: (as you've basically said yourself)