Jak525

Our Hornet is not 20X nor 15C nor 21X nor 19C nor 91C. It's a frankenstein roughly circa the 2000s with some stuff from the 2010s and other things erroneously added from like, the 1990s. That said these are from I believe at least 15C (2001ish). Generally what's important is to get features in the "post-MSI" era as opposed to before that. This was 15C+, and is when a lot of things were overhauled with the integration of sensor fused MSI trackfiles. The Az/El format entirely, for example, was an invention that came with MSI.

The post Hulk linked has a lot of the missing things. Another rather annoying thing is the automatic format selection on the left DDI. In DCS right now entering either A/A or A/G master mode brings to the Stores format. In AA, with the FLIR loaded, it brings up the FLIR which is just completely wrong and defeats the Az/El HOTAS mechanic with the FLIR and STORES pushbutton shortcuts. What should happen is the left DDI is actually unchanged when entering a master mode. However, in NAV and AG Castling left will bring up the Stores format and in AA Castle left brings up Az/El. Castle for Az/El is implemented in DCS but not for Stores in AG/NAV, which'd be handy. The bigger issue is the Stores/FLIR formats raining on your parade whenever switching between AA and AG master mode. Very difficult to use. Note the invoking of the Stores and FLIR format via master mode change seems to be from a very old OFP, predating things like the AzEl format entirely. With the later avionics it is very very annoying.

Do you have evidence that supports the current implementation? If that were the case I'd understand. However, faced with no evidence supporting one behavior and pilots with real experience supporting the other behavior, it makes little sense to go with the former. You are asking for evidence that something CAN be done, when it has been arbitrarily limited already (if you don't have evidence for said arbitrary limitation).

Good find. IIRC, it is correctly implemented that the climb IAS is removed from the HUD outside NAV. However, the CLIMB pushbutton should also be removed outside NAV. Quite clear here.

Unlike JDAM PP, the HARM PB points can only be loaded via the AMU. There's no way to enter them by the UFC or anything. So that's likely why they've been omitted for now.

Harker has explained trackfiles and the workaround for the current implementation great, but just an obligatory note that this current implementation is incorrect/eventually up for a fix. The ageout setting should only control how long raw hits stay displayed, visually, but has no affect on trackfiles. A trackfile is maintained until the radar declares memory, a function of frame and not time. E.g., radar completes entire frame of bars (sweeps each bar once), never sees the target. At that point memory is entered for that track. It flashes (not fades, only hits should appear to fade) for some time and is then completely deleted. This has no connection at all to the age out time the you can set on the DATA sublevel. Since the hit setting is purely time based and can be as long as 32s, the hits might be displayed for a bit even after the trackfile is deleted and the HAFU is removed, if the behavior was correct.

Yes. The NO RDR cue in that clip specifically is shown briefly as the MC is creating the MSI trackfile from ACM, so an odd example. The NO RDR cue however is absolutely there to indicate there is no Radar contribution to the L&S target when an AMRAAM is selected. Otherwise (e.g. Sparrow or Sidewinder, or NAV master mode), NO RDR would not show up, but you would not see RADAR or R in the HUD sensor contributor window, and the HAFU would be lacking the radar contributor circle on the Attack/AzEl/SA. Cuing for a "lost" Radar trackfile, i.e. one that's gone into memory, would be the "R MEM" cue (Radar MEMory) on the HUD just above the sensor contributor window (not on the TD box). If all contributing MSI sensors are in memory then the TD box is also hashed. However R MEM shows up if the radar is in memory, even if other sensors aren't. On the DDIs you'd see the radar contributor circle flashing, or if all sensors are in jeopardy (or if the radar is the one and only sensor), the entire HAFU symbol flashes. Regardless NO RDR could only show up after the radar has done its memory phase and been completely dropped. I wouldn't focus much on changing this thread's tag. I can tell you that there are people on the team that know what they're talking about. Don't worry too much for now at least.

Bunny is right. That said IIRC the Hornet avionics displaying the launch zones have not yet been updated in accordance with the AMRAAM performance rework. So your cuing is representative of the AMRAAM pre-rework. So it's a very very conservative if not completely inaccurate cue.

A Hornet, C Hornet, and Super Hornet avionics were practically identical in this timeframe—i.e. APG-65/73 radar—avionics-wise, especially regarding sensors/weapons systems. For a time they literally gave them the exact same OFP (software) designations.

@HarkerThe term "offboard" is used to refer to datalink MSI tracks specifically. An onboard track is radar and/or FLIR etc (anything but F/F, PPLI, SURV). Just a piece of trivia, the Litening radar slave function we have is based on an avionics implementation prior to MSI. Basically, that's how it was done before they just invented the idea the FLIR would contribute to sensor fusion. That was removed, as it's unnecessary when you can simply command the radar to STT onto a FLIR-only HAFU (placing Attack or Az/El cursor over it and Castling toward format; Fast Acq). The A/A slaving modes we see on the ATFLIR in-game are what it was changed to, hence the lack of any direct radar-to-FLIR button on that. Other things: when a trackfile does have Radar contribution, a circle should appear inside the main HAFU shape, and outside the rank number/L&S star. A FLIR-only track would be angle only and without the circle. Also, designating a non-radar L&S should display NO RDR on the Attack format (bottom left region). With an AMRAAM selected, "NO RDR" is also drawn on the HUD under the TD box. (Picture attached.) (AMRAAM could technically be launched without radar but then you run into probably missile guidance issues since the radar is used to send it datalink commands even though the fact the radar is looking at its target is technically irrelevant). Side note. A 20 year old F18 sim-that-shan't-be-named, which Wags actually worked on actually had all this fleshed out well, with designateable datalink tracks and stuff. Additionally I'd note that whole reason the HUD says RADAR when you have an L&S is because there can be multiple sensor contributors. Paging @Mo410 if he has any additional comments. Lol (pic from this cool show: https://youtu.be/JwsIkiZEVhI?t=1636)

Absolutely. In Autotrack, the FLIR sensor is driving the designation. It's in track. That's why you see "FLIR" on the HUD while in Auto/Scene but not while in regular designated pointing. The designation should be constantly updated in Autotrack/Scene track.

More than sure. HAFU symbols (MSI trackfiles) are supposed to appear basically identical on the Attack, SA, and Az/El formats and can be interacted with in very similar ways. You should always be able to cursor over to see the altitude/Mach and even designate them as the L&S/DT2 from the three formats. Only thing you can't do from the SA is go into STT. Furthermore, when a track is designated as the L&S or DT2 track, it should have its Mach/altitude always displayed, on all three formats. The Link-only trackfiles are also pretty messed up. You should be able to designate them before the radar sees them. Very importantly, the Mach/altitude should be shown when they are under the cursor (currently only works on the SA). Basically, the system should be much more easy to use without any cumbersome swapping between this and that format. The only information completely UNIQUE to the SA is the stuff in the data windows in the bottom left and right like PPLI callsign, fuel state, etc.

Oh also related. Since MSI stops, all trackfiles should be deleted in ACM, including link 16. Right now you can still see link tracks.

No, ACM deletes all trackfiles and MSI processing stops while in ACM. You should however be able to return to RWS/TWS while maintaining the L&S. That doesn't work though and is a bug. Related to that, another bug is that when in ACM, the RTS mode is that ACM mode. Rather, it should be the main mode that the ACM mode was entered from. E.g. going TWS > WACQ > STT would show "RTS TWS" in STT and return to TWS upon hitting Undesignate. Only exception is with the gun selected in which case Undesignate will return to GACQ, since RWS/TWS aren't available.

Ah OK, double action. Single action is causing the raster now, and there's no RWS scan centering available whatsoever.

What you're seeing is an attempt at acquisition; a mini raster scan. What should happen, though, is a TDC depress in RWS over empty space sets the center just like TWS MAN. It's definitely wrong at the moment, and the lack of centering ability in RWS (aside from Spotlight) makes RWS quite hard to use. Such a basic function. Mini raster should only happen when a hit or trackfile is determined to be under the cursor I believe, and the TDC is pressed (Manual Acq) or Castle switch is bumped (Fast Acq). Of course TDC depress over a track would designate it first; only over the L&S would do STT and the mini raster. Castle will always STT though. Paging @Mo410

DCS is exceptionally clunky and wrong at the moment. The trackfile's altitude should be able to be seen on the Attack format, without going to the SA. Removing TDC priority from the Attack format should exit Spotlight and remove the cursor from the Attack page entirely though. Cursor should only be visible when TDC is assigned to the given format. In the end, the whole swapping between SA and Attack should NOT be a necessary part of the workflow. You should be able to purely reference the Attack format. The advantage of the SA is 1) shows targets behind you and 2) shows some more detailed data on the MSI track like callsign and whatnot. Ultimately, a complete redo of MSI trackfiles is required. You shouldn't need to go the SA format for one thing and the Attack/Radar for another, except for that detailed information the SA provides in the data windows that is not on the Attack format. In fact, those data windows should display on the SA for the target under cursor on the Attack. So you can simply glance at the SA for info on the target you have under cursor on the Attack, without assigning the TDC to the SA and slewing the cursor on the SA itself. Same for Az/El.

Uses your own bar and PRF. 22° azimuth.

Spotlight mode accomplishes this exact thing. Press and hold the TDC for more than 1 second. The SPOT cue appears and an X is drawn in the center of the cursor. As a bonus, it's even space stabilized.

This works much better than the previous implementation. Let me lay it out: AUTO - TWS automatically maintains the L&S and DT2 trackfiles. BIAS - from AUTO, the TDC is depressed/released. The scan center is shifted to that azimuth, but the L&S and DT2 are still forcibly maintained in the volume. As such the center may not be fully honored, since maintaining the designated trackfiles is the primary objective of BIAS. MAN - TDC is depressed/released. The scan center is centered at that azimuth without regard for the L&S or DT2 targets. The confusion stems from the fact that the previous implementation of MAN and BIAS were completely and utterly incorrect.

No. Use MAN. Depress and release the TDC to set the center. BIAS was previously a pointless mode. Now it has a purpose. The idea of BIAS is to "bias" the AUTO scan center. Basically you can shift it left or right, while still maintaining the L&S and DT2 targets.

Spotlight should work in TWS. The new behavior is correct for MAN centering. The previous mechanization was wrong. The scan center is defined by depressing/releasing the TDC. It does not follow the cursor. The only "cursor following" mechanic is Spotlight. TL;DR no bug, MAN was fixed this patch, it was wrong before

I'd note it's mentioned in the Early Access guide.

Not modeled, but reported IIRC. AMRAAM shot from STT = RTS mode becomes TWS, even if STT'd from RWS previously.

Awesome insight. Sadly the radar physics aspect of this whole thing is not yet applicable in DCS. Hopefully one day we see an advanced enough simulation to see something like this. Regardless we can still have the modes to make the avionics 'feel' realistic even if the physical radar beams are rather simplified.