Jak525

Looking into it, that description on the wiki is not entirely correct I don't think. Will investigate and report back with hopefully an explanation.

STT does generate a trackfile; it wouldn't show a HAFU or appear on the SA format otherwise. A trackfile does not need to be something predicted. All it is is an object in the air the computer sees as a single object based off the own radar and/or datalink donors (even if the radar gives multiple raw returns, they can be determined to be trackfile/HAFU) which is assigned a known speed, heading, altitude, position, identification, etc. The radar drops the lock, yes, but why does it forget about the trackfile? Exiting STT is no different than the radar sweeping over the trackfile. It saves its last known parameters from the sweep, or in this case from the last moments of being in STT. "It can't use any previous data as it can be invalid" - this is no different than the radar sweeping over the contact in search mode. The moment after it sweeps, said info may be invalid.

There are some odd things about Single Target Track (STT): - HAFUs are never colored. - Donor information is never shown (I think this has to do with the bug where a separate HAFU sort of exists in its own bubble when TUC'd or designated as L&S/DT2). - The trackfile in STT is dropped when you exit STT. This seems very odd to me. I understand it drops all other tracks, but why does it lose the track you have in STT? What I mean by this is that the trackfile/target in STT disappears when you exit STT, and the radar has to sweep over it again to find it. Seems like it should be kept (and of course if it can't find it, eventually drop it in line with the aging setting). I'm quite confident the above things are bugs. Another thing I'm unsure of, but worthy of note, is that offboard trackfiles don't get shown in STT. I can see how the radar blanks all other onboard tracks when entering STT, but I'm curious if it's supposed to show offboard trackfiles still - which would make sense for better situational awareness.

Track attached. It appears this bug comes up when you make waypoint 0 the A/A WYPT. SA BE bug.miz.trk

It seems pretty odd that hole in the blanking exists between the HUD and the glareshield. Are we sure that isn't a bug?

It's relative to the pipper, not the target. If the pipper is perfectly over the target and it's pulling 1.0G then the 1G symbol should coincide. But it may not be 100% accurate at very close range; I think the FORESIGHT is intended mostly for near-maximum range gun shots.

The DCS FA18 manual states: "While in RWS mode, the RADAR can maintain up to 10 trackfiles." This is currently not simulated. Instead, we can have (from what I could see from testing) infinite trackfiles basically. What I think should happen is, once 10 trackfiles exist, only raw contact bricks display on the RDR ATTK page for any further contacts and given no trackfiles are generated from them, the SA format does not show them.

I think the issue here is when a HAFU is designated as L&S or DT2 or is under the cursor on the radar it essentially exists in its own bubble. Not only with its identification, but often the trackfile rank is also different - plus the already reported bug where the bottom HAFU isn't shown at all when cursoring over or designating.

They said they'll add this. You'll be able to get rid of the STEP box by just moving the TDC, which will make the cursor re-appear.

All trackfiles in LTWS are working. The DT2 on the HUD and trackfiles on the page in general do seem to look a little choppier now though; I think it's got to do with the (already reported) bug of donor info not showing with a designation or when under cursor; they seem to be in their own world when designated or cursored over vs. not, and when not they appear choppier on the radar.

The sound is for the AIM-9's seekerhead moving to high off boresight. It follows your head if the HMD is on; as Rescue said, the HOTAS button just blanks the symbology.

Shouldn't it show anyways for a PPLI? Say Hornet A sees Hornet B on radar. Hornet B broadcasts over the PPLI system on datalink to Hornet A that himself, Hornet B, is a friendly. This covers the offboard identification bit - Hornet B identifies Hornet B as friendly via PPLI, and so Hornet A sees Hornet B as offboard friendly. The Hornet marks a trackfile as onboard friendly in one of 3 ways: - Manual PLID - Friendly IFF interrogation - Has it on PPLI Hornet A sees Hornet B on PPLI. Thus, Hornet A identifies Hornet B as onboard friendly. Hornet B is also offboard friendly because of PPLI. THUS: The HUD should show a square with a friendly HAFU above, because Hornet B is both onboard and offboard friendly to Hornet A.

Aye. The RWR bearings would be especially helpful as well.

No, the half-circle is only for a datalink (PPLI, SURV, F/F) source saying it's friendly. The onboard friendly identification isn't indicated on the HUD (well, the square means it's not hostile, but nothing changes from unknown).

This is intentional behavior, it only works in night mode. Heard this from Wags in a livestream (quite a long time ago).

Indeed - I believe this is one of the main ideas of the STEP box, so the trackfile can be seen cleanly. Also, it seems the velocity line that shows in your image pokes through the STEP box. I'd imagine the box should be slightly taller to encompass it entirely.

I notice you can take a SURV or F/F trackfile, which is not detected at all by your own radar, and PLID it. Is this really correct? It seems odd since onboard identification seems like it'd be paired with it being an onboard trackfile.

The bullseye indication in the upper-left of the SA format seems to be gone. It used to indicate the BRA from the bulls to the TDC cursor. Was this found to be inaccurate or is it a bug?

When we get the Azimuth/Elevation format, this would become a realistic scenario I imagine, with the AZ/EL on one DDI and the RDR ATTK on the other.

Recently I saw Wags mention that we'd be able to see an ambiguous HAFU symbol if the donor and ownship HAFU were conflicting with the new PLID feature. This never happens.

Unfortunate, but this means that we'll hopefully a) have less bugs and b) less un-implemented features at release.

Indeed. Also, when a DT2 exists it will instead swap the two. I reckon this is a good way to make a really quick double AMRAAM launch in TWS - trigger, Undesignate, trigger.

Something I think however we're missing is the ability to use the SCS to get those master mode pages back when in that master mode (and as Harker mentioned the HSI/SA swapping). I believe for example in A/A master mode, if you got rid of the RDR ATTK on the right DDI, and then did SCS right, the radar should come back up.

Negative (this is an error in the DCS manual confirmed by Wags). ACM mode is exited via the Undesignate button (pinky button on stick). Here's a current resource https://wiki.hoggitworld.com/view/F/A-18C

Potentially a low closure rate, is beaming you, or (this is probably it) your trackfile/contact aging setting is very low. Head to the DATA sublevel; the top right corner gives you an option to set in seconds. Try the maximum of 32. If the Mig is the only contact around, use Sensor Control Switch right to activate Automatic Acquisition (AACQ); be sure to be in A/A master mode for this. AACQ will enter Single Target Track (lock) as soon as it sees something pop up. P.S. Track While Scan isn't in yet. You probably mean Range While Search (RWS) with Latent Track While Scan boxed; RWS processes trackfiles just like TWS, it just doesn't support AMRAAM guidance nor does it limit the scan volume.