Jak525

Sorry for going off topic here lol. Anyway: What I said applies to air to air hits. I honestly don't know the proper behavior for GMT. In air to air, two hits is enough for an extrapolation. I don't really know how it's supposed to be for GMT. What you're saying makes sense but it all depends on whether the Ground Moving Target Indication (GMTI, the bricks in GMT) is a trackfile or not. If GMTIs are completely raw then what we see in DCS is surely wrong and it should just work like A/A should work as I explained. If GMTIs are extrapolated, then it wouldn't be wrong for them to move between radar sweeps. However, as you noted they should not move until there's been at least two sweeps, so that the heading/speed can be determined and then the position extrapolated. It's also quite weird how in the video we saw the hits "jumping" ahead before and after the antenna swept over them. If they're extrapolated then the movement should be smooth. The jumpy behavior would be more like true raw hits.

No, a trackfile and a hit are different things. A trackfile is represented by a HAFU symbol. A hit is represented by a brick and isn't influenced by trackfiles. LTWS is also modeled quite incorrectly right now. LTWS right now "turns off" trackfile processing basically. What it should do is simply toggle whether cursoring over a raw hit displays its HAFU symbol, versus just the altitude of the hit. However, with LTWS deselected, the trackfile processing still happens under the hood and you would still see the L&S and DT2 as HAFU symbols, if designated, as well as, when MSI is boxed, any datalink-contributed trackfiles. Regardless though, hits are intended to be raw radar data. Trackfiles (HAFU symbols) are extrapolated/correlated based off those hits. Hits themselves should stay in one spot in space.

They are sometimes correlated where when a new hit is detected the old one disappears. This should never happen. Once a hit is detected it's frozen at that position and will only disappear when the elapsed aging time is up. This creates a "history trail" effect. The longer the aging the farther back you can see.

Air to air hits are 100% wrong. It's possible that GMT hits are like pseudo trackfiles or something though. Honestly don't know. But I wouldn't be surprised if ED's implementation was wrong given how air to air hits have been wrong since release.

They made a change iirc, but now it's literally always X'd out.

Yeah definitely shouldn't sever missile support. And yea, I sure hope hits get redone soon. It's such a fundamental. And yeah, the DCS manual actually says that which is right, but in-game 'promoting' those raw hits to trackfiles doesn't actually work. And RSET should reset those "manually filed tracks", although thinking about that fringe case if you had AMRAAMs in flight against those last-ranked tracks (say #9 and #10), those tracks would actually be the top priority trackfiles after the L&S (if one of them wasn't also the L&S), even though the ranks are still 9 and 10, so they wouldn't get deleted with RSET anyway.

I don't think ERASE should actually delete trackfiles. It should just remove raw hit bricks. RSET definitely shouldn't affect AMRAAM datalink support. Ranks should also be unaffected but that ties into another bug of the L&S/DT2 affecting rank, and also the difference between track priority and traxk rank.

LOL, sigh. Of course. It was working right for a time, definitely.

When the Sensor Control (Castle) switch is pressed forward or the Gun is selected, the radar enters the ACM condition. This is of course implemented already. This should also command the Attack format to be displayed on the RDDI and automatically assign TDC to the Attack format. The TDC assignment function actually works, even if the Attack format is not on the RDDI. Invoking the Attack format after entering ACM with the TDC previously not assigned to the Attack format does indeed assign TDC to the Attack format. The problem is, however, that the Attack format is not invoked on the RDDI when ACM is entered. It should be. In short: Current behavior - Entering ACM assigns TDC to Attack format, but does not invoke Attack format on RDDI if it is not on the RDDI already CORRECT behavior - Entering ACM both assigns TDC to Attack format, and if Attack format is not on the RDDI, displays Attack format on the RDDI Info PM'd. ACM does not invoke Attack format bug.miz.trk

I edited the post when I bumped it

Bump as I PM'd Bignewy the info. Thanks for looking when you have a chance!

Bumping and PM'd info. Sorry, I thought I did originally.

Bump, I think this got missed. Also edited the OP for further clarity.

In an ideal world for sure, and I'm not against things being added later. I'm just saying the priority right now, since ED has limited resources, ought to be improving what we already have.

I don't mean to detract from the topic, but God guys, how about we let them polish off the many bugs and incorrect and/or missing functions from the current weapons and systems rather than asking for even more weapons, even if the C model can carry them.

The HARM Pre-Briefed (PB) mode will provide range-informed guidance, yes. It has similar basic symbology to AUTO mode for conventional/laser guided bombs, with a release cue and azimuth steering line, among other functions.

Hi, thanks for looking into it. As I quoted in the PM it says here: "selecting the EXP option causes the radar attack display to be expanded about the L and S target. The radar freezes the B-sweep at the azimuth of the L and S target based on a 140° azimuth scale."

The RSET option on the Attack format (PB14), when pressed, should be boxed for 2 seconds. This behavior is already implemented for the SET function in RWS at PB13, so the code just needs to be copied I assume. Small thing that looks like it was missed at some point. Proof PM'd. RSET boxed bug.miz.trk

Currently, EXP can be selected with an L&S below 5nm. The correct behavior should be that when the L&S is within 5nm, the EXP option at PB20 is removed from the Attack format. EXP is not usable. Furthermore, if previously in EXP at farther than 5nm and then the L&S gets closer than 5nm, EXP should be automatically exited. PM'd Bignewy the info. (Note RAID already does this, so the same logic must be applied to EXP + removing the EXP option itself.) EXP bug.miz.trk

Currently, in EXP, the B-sweep remains unchanged sweeping back and forth relative to the 140° scale. Instead it should be frozen to the azimuth of the L&S relative to the 140° scale - not sweeping back and forth. In other words, exactly how SCAN RAID behaves already. This behavior is stated in the DCS F/A-18 manual (page 235). I also PM'd secondary info. Thanks! EXP bug.miz.trk

The bug is that the designation currently won't move in FLIR Point Track. As such the Maverick is not slaved to its constantly updated line of sight.

L&S and DT2 designations only exist for user interface purposes. The radar will support an AMRAAM against any trackfile. https://wiki.hoggitworld.com/view/F/A-18C

Bunny, correct. There's also the issue (which I reported) of the L&S "bumping" every trackfile's rank up by one. What should happen is if the #1 is also the L&S, the Acq Point Cue is not present. (There's a bunch of demonstrative pics in my report if curious).

I already messaged Bignewy the detailed explanation and source but making this its own separate report as requested. Current behavior: 'WSPN' indication on the Stores format reads 'WSPN XXX' when wingspan has not been set. Value actually defaults to 40ft (and behaves as if set to 40ft) but is "hidden" until a manual value is given, at which point it says WSPN 100, WSPN 030, etc. Correct behavior: Three letter X's should never display after 'WSPN'. It should just say the number even when default (WSPN 040). 'WSPN XXX' is just used to indicate a placeholder value in the documentation; it should never actually be displayed. (Again already PM'd source and further explanation.) Thanks!! WSPN indication bug.miz.trk

A recent patch fixed the indications for when there's no laser code set for LGBs. The indications are correctly X'd out. However, you can still release the bombs without a code set and the indications X'd out. LGB releaseable with no code bug.miz.trk