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)

When interrogating hostile contacts with IFF, hostile targets appear to incorrectly return what appear to be partial M4 return symbology (yellow square, though incorrectly scaled). After acquisition into STT and NCTR interrogation, the hostile target I was using (a MiG-23) to test appeared as a green friendly track. Needless to say, both of these things seem very wrong. The mission I tested with had no other aircraft to contribute datalink information for target classification. I have not tested what the behaviour is with datalink in play. The mission I was using to test and a track are attached. Viper IFF Test.miz F-16 IFF Test.trk

This is a serious problem that makes designating targets with the FCR cursor very difficult. The Hornet suffers from a similar problem when trying to make a TGT using the A-G radar, probably the same underlying issue.

It has nothing to do with data cartridges specifically. In the Viggen it's used to select a data cartridge, but in the F-5E and almost all other modules it is simply used to select options that the ground crew would set on the jet or weapons on the ground outside the cockpit, as you can see. If ED adds a full aircraft configuration panel that allows these settings to be changed then the kneeboard method will be moot, but until then it's more or less the best method for allowing settings like that to be changed. (The JF-17 has a different system for changing laser codes that allows individual pylons to be configured to different codes via the ground crew menu, though this is technically also possible via a kneeboard implementation.)

I have been flying and greatly enjoying the Mirage F1 over the last couple of days. However while playing I have been thinking of a few additions or improvements that could be made to the overall interface of the module which, in my opinion, would greatly improve the player experience: The ability to change aircraft settings in-mission: Currently laser codes, countermeasure programs, burst and salvo settings seem to be only selectable from the mission editor. This is fine for pre-canned single missions but in open multiplayer servers this makes it impossible to adapt the jet to the situation or player preference, since the ME is not accessible. Currently, the standard method for changing settings like this for the vast majority of modules in the game is via the kneeboard, for example as on the F-5E here: This is a fairly good way to do things since it allows the aircraft to be set on the ground after spawning in, but the options are locked in the air where they would obviously not be accessible to the pilot, and I would love to see something like it implemented. (I love the inclusion of checklists on the kneeboard by default by the way) For countermeasure programs and burst/salvo settings another option would be to be able to override the ME settings through the Special Options menu, as seen for example on the JF-17 here: This would allow players to set their preference and not have to fuss with things when entering a mission. However, I think the ability to change things in-mission should be the priority. Add a Special Option to force enable or disable the radar cover: Related to the above, the current method for removing or attaching the radar cover shroud is perfectly fine for ground starts, however it is impossible for a player to adjust it for an air-start mission. Having an option in the Special Options tab to force the shroud on or off (or leave it according to ME settings, of course) on all missions would both make this possible and generally make it so players have to fiddle with less things to configure the jet to their liking when spawning in. Idle and afterburner detent zones: This has been mentioned a few times by others on the forum. The F1's throttle seems to have a large range of travel dedicated to the afterburner which makes it difficult to control in normal flight with most consumer throttle. Adding an option to set how much of the travel is dedicated to idle and AB would make things easier for players to adjust to their setup. For example, the Mirage 2000 has an option like that in the Special Options tab of the game: More keybinds: There are some bugs with the keybindings that you are probably aware of, but besides those, I think adding additional options to go directly to various radar modes and range scales, for example, instead of only incrementing them up and down one by one, would be very welcome. Faster dial scrolling when clicking the mouse and dragging: Currently it is very time consuming to adjust dials such as the TACAN additional target bearing and range, or the fuel indicator. Making it so that clicking and dragging the mouse on these dials will adjust them faster, while leaving the scroll wheel slower to make fine adjustment, would make it much easier to handle those systems. This could be tied to an option in the Special Options tab so players can adjust the speed to their liking. Adjust or display fuel quantity as of last refueling/rearming: Currently refueling in-missions seems to automatically reset the fuel indicator to the correct level, but attaching external fuel tanks does not seem to change it, leaving the player to have to manually calculate how much fuel they should have or make adjustments to it. Either automatically adjusting the quantity based on what external tanks were loaded (or, again, having an option in the Special Options for that) or leaving a note on the kneeboard for how much fuel was loaded on the jet as of the last time it was refueled and rearmed would make this a lot simpler. For example the Mirage 2000, which has a similar fuel system to the F1, displays such information on the kneeboard: This would be beneficial for future variants with air-to-air refueling capability, where a message from the tanker about how much fuel was transferred could be noted down to allow players to adjust their fuel totals appropriately.

Using an identical simple test setup with a co-altitude target hot off the nose of the aircraft, I am able to detect the target at fairly consistent ranges (a bit over 50 miles for the MiG-31 I'm using here) but the radar will not allow me to initiate a track until a seemingly arbitrary closer range. In one instance I've managed to track the target in SAM very shortly after it was detected, and in another I haven't managed to bug the target until it was within approximately 12 miles. This seems to happen in both RWS/SAM and TWS, though I've only tested TWS once. What I would expect to happen is that the radar should allow me to initiate a track as soon as the target is detected on the scope, and if the track is unreliable then it might drop as subsequent sweeps fail to detect the target. (I'm not sure if probabilistic detection is supposed to be implemented on the radar right now but in any case the target was being consistently detected by all sweeps after initial detection.) I've attached two DCS tracks showing tests, in one of which I managed to obtain a radar track on the target at about 47 miles and another in which I couldn't manage to until 24 miles. I go into VS at the start of the 24 mile test because I had a feeling doing that might be contributing to the issue, but I'm not sure it really matters. JF-17 Detection and Tracking - No VS.trk JF-17 Detection and Tracking - VS first.trk

Indeed. If: closure velocity = (own velocity + target velocity) for a hot target closure velocity = (own velocity - target velocity) for a cold target ground velocity = (own velocity) Then simple math will show you that if the closure rate is the same, it does not matter whether the target is hot or cold. The difference between the relative velocity of the background clutter and the relative velocity of the target is the same. I'm pretty sure in the tests I did here there was even a higher difference with the cold target. Ultimately this is not how a radar works anyway. If you're well outside the various blind velocities of the radar then the detection range does not scale with closure velocity like that, especially not to this magnitude (and as it happens a target that is close to the beam is typically the easiest to detect due to increased RCS, though DCS does not generally simulate that). Also these tests were done in look-up over water so this is doubly irrelevant.

As of the current patch the Hornet appears to be unable to detect or track helicopters on radar. Both standard search and ACM modes appear to be affected. I have attached a track showing me trying to detect a closing Ka-50 from 20 miles out, switching to ACM at close range. I was unable to acquire it in any way. I've also tested this with an Apache AI unit. The F-16 appears unaffected so this seems to be a Hornet only issue right now (I haven't tested other airframes, though). Hornet Helicopter Detection.trk

When attempting to detect and track radar contacts, radar performance seems to differ drastically depending on whether the target is presenting its tail or nose to your aircraft, even with identical parameters and in particular identical closure rate. I set up a test with a B-52 flying towards and away with me with my aircraft and the target at different airspeeds to bring the closure rate in line: In the tail chase scenario, with a Vc of 550 knots, the target was not detected until 50 miles and STT could not be acquired until 34 miles. When the target is hot, it can be detected at ranges in excess of 85 miles and I successfully managed to track it at 77 miles even with a much lower Vc of 470 knots. Additionally, it seems that the behaviour of the radar in different PRF modes is also inconsistent with target aspect. When attempting to detect the cold target, MPRF picked up the target at ranges exceeding those at which HPRF could pick it up: https://gfycat.com/incomparableunconsciouskoi When targeting the closing target, MPRF could not achieve STT at ranges where HPRF acquired instantly, even at a lower Vc: https://gfycat.com/powerfulenormoushamadryad Tracks for both tests are attached. I'm guessing all of this might apply to the F-16 as well, but I haven't tested it. Cold Target.trk Hot Target.trk

In Wags' latest video on the F-16's A-G radar, the GM EXP mode is shown as blacked out on the area directly in front of the nose of the aircraft, as when doppler beam sharpening modes are in use. From my understanding this is not correct behaviour: EXP should simply zoom in the normal ground map and doesn't rely on doppler variation to display the image, so it should not be affected by the angle of the scan in the same way. For example, in this video you can see the transition from NORM to EXP works just fine with the cursor in front of the nose of the aircraft, and the offset maneuver is only performed when they transition to DBS: https://youtu.be/qg1Ojydzv8U?t=1308 Additionally, at least in the MLU M1 manual, when DBS modes are in use the radar image should gradually revert to real beam resolutions when at too low of an angle from the aircraft's nose, rather than blacked out.

Can we expect to see improvements to Rockeyes and other conventional cluster munitions in the game as well?