Jak525

You can disable MSI from the radar DATA submenu. It'll remove the Link 16 contributions, among other things. Just a note, it should be done from the SA format SENSR sublevel (which works right now as far as I know). Although it works right now too, the Attack format "MSI" option is completely incorrectly modeled right now. It, in fact, has no bearing on MSI processing and simply toggles whether trackfiles with non-Radar contribution are displayed as HAFUs on the Attack format in RWS. ED had it more or less right once, then broke it.

I know that it absolutely should. The reason for this is because Fast Acquisition is considered a sub function of AACQ and ultimately, when the cursor is over a track other than the priority one, bumping the Castle switch will acquire the target under the cursor and not the point cue. So, it's blanked when the cursor is over another track to make it a completely consistent cue.

With the AMRAAM selected and the target within Rmax, the XXX ACT cue on the HUD should show the computed Time to Active for the missile under the trigger before it is launched. If the missile is close enough to go active (mad dog) immediately on launch, it should say 0 ACT until being fired and then transition to the TTG cue. This is actually properly done on the Attack format already. You notice in the track once I get within Rmax the pre-launch TTA is displayed below the bottom edge of the tactical region. (Note, however, on the Attack format it is just a number with no "ACT" text; this is because this number is always for the pre-launch/missile under the trigger, while the fly-out cue under the target indicates the timers for an in-flight missile.) The cue simply needs to be added to the HUD for pre-launch. Once an AMRAAM is launched, the ACT cue currently displays properly. It simply needs to be added pre-launch, and again, it seems this value is already properly calculated pre-launch as well, hence the proper Attack format indication. Side note: I could have sworn this worked properly in DCS once and got broke... but I could just be misremembering entirely. AMRAAM ACT cue bug.miz.trk

Note the Acq Point Cue doesn't actually always indicate the point of AACQ right now. The priority (as opposed to rank) logic for trackfiles is not yet implemented, so it's sort of useless. Basically when an L&S target is designated it shouldn't be shown. Also shouldn't be shown when the cursor is over another track.

The Expand (EXP) function of the SA format should be toggle-able via HOTAS, using the Event Marker button on the control stick. SA Event Marker EXP bug.miz.trk

On the Attack format it should be possible to change the azimuth by bumping the cursor on the left and right sides of the tactical region. On the Attack format it should be possible to select almost every option with the cursor instead of using the pushbutton. On the SA format you should be able to use the cursor to increment / decrement the range by bumping it near the top and bottom of the page. On the SA format the Event Marker button on the stick should toggle the Expand (EXP) function. The Castle switch actually uses the depress as a modifier. IFF interrogation should be depress then right, not just depress. Depress then aft I believe pulls up the TGT DATA format. Castle forward twice quickly toggles EMCON mode. There are some other missing "HOTAS-related" functions but they are more so entire functions and not just HOTAS shortcuts, for example manual scan centering in RWS on the Attack format. Honorable mention that's HOTAS-related. The cursor on a format should only appear when the TDC is assigned to that format. Otherwise it disappears. You see this implemented correctly on the Az/El but not on the Attack or SA. I don't know which software revision this particular one is as the mechanic has changed, but in NAV and A/G you can Castle left for the Stores format. It was also changed that the LDDI no longer automatically pulls up the Stores format when changing master modes.

Current Behavior. TWS scan centering currently remembers the last scan centering mode (AUTO or MAN) when switching through modes (e.g. STT or RWS). The one exception where it is correct right now if both a) STT has been entered from RWS and b) TWS is entered via the TWS pushbutton (PB10), AUTO will be selected. Intended Behavior. Instead, it should behave as such: When entering TWS from STT, either via pressing Undesignate, selecting the RTS option (PB5), or the TWS option (PB10), the scan centering mode is automatically set to AUTO. When entering TWS from RWS or (when eventually added) VS, the scan centering mode is automatically set to MAN. I PM'd Bignewy. Thanks! TWS AUTO MAN defaulting bug.miz.trk

The problem here is trackfiles aren't being deleted period. Upon entering ACM all onboard trackfiles should be deleted. And, to be clear, this includes the L&S.

The ghost cursor is a very modern addition. Probably won't see it. What should, however, happen for the "pre-ghost cursor logic" is that a cursor only appears when TDC priority is on a certain format. This is properly done on the Az/El, but missing on the Attack and SA.

So, uh, a quick test of the issue here indicates there is no bug. For the issue OP mentioned, I am still able to use the STEP function while in the SA Expanded view. Furthermore the issue Ziptie mentioned about the STEP box not cycling trackfiles when entered after cursoring over a trackfile doesn't seem to be present either. It appears to be working as intended. I cursor over a HAFU, press STEP. STEP box appears over that HAFU. Subsequent presses of the STEP button cycle each trackfile. Yep, it's a pretty big issue. I think they need to rework/improve the entire MSI trackfile system at some point probably, and ensure it's all synced up.

@Ziptie Chuck's guide isn't ED's manual, so not for ED anyway. I actually looked up that statement about non-friendlies and looks like what's from Chuck's guide is actually from the Hoggit wiki's F18 page which I maintain. Didn't realize that was there, but I've amended it. Might've been put there due to the SA format not ranking friendlies (trackfiles on the SA vs. AzEl/Attack are in their own two bubbles as I'm sure you've seen, a big issue in and of itself as well). As for cycling contacts with TDC priority not on the SA format, that makes sense, though not sure if that should actually be possible. Could be though. By confusing wording I meant this sorry: "when TDC priority is on the SA page, STEP does not "replace" the TDC with the rectangular box (this is only achieved) when TDC priority is not SA page."

@Ziptie One - I think at one point in DCS it only stepped through non-friendly trackfiles but it should step through everything by rank now. Second - Pretty sure it should still cycle through all HAFUs regardless. However, if the cursor is over a HAFU that trackfile is the first track STEP'd to. But it should still cycle thru everything after that. Third - Your wording is confusing, I think there might be a typo there haha. But, the fact the cursor shows on the SA format with the TDC NOT assigned to it is a bug in and of itself. Cursors should only be displayed on formats when the TDC is assigned to them. You see this properly implemented on the Az/El format but the SA and Attack formats haven't been fixed yet. From another Hornet sim I believe that the STEP box should only be available when TDC is assigned to the SA as well, since it's basically a replacement for the cursor, and the cursor should only be displayed when TDC is assigned.

The real TWS AUTO scan centering, as I'm sure the devs know, has a more complicated logic incorporating a priority mechanic and ultimately tries to maintain as many trackfiles as it can. Especially considering Heatblur modeled the F-14's TWS AUTO, which is similar in the general idea, it'd be great to see in DCS on the F/A-18. Thus my question is: is AUTO centering ever planned to be expanded or will it always be simplified as "AUTO = centered on L&S"? I'm not asking when, just if it's in any long term gameplan whatsoever or if this is it.

Yeah, no bug here, at least what the title is. Those two unknown trackfiles should actually have their HAFUs displayed in RWS mode assuming the MSI option is boxed, but that's for another bug, that's already been reported. Regardless the raw hit and acquisition point cue is there. Bottom line is the 4 targets are being displayed in some way, so there is no big here with regard to the hotfixed issue of targets not displaying at all at certain range scales.

Just like the range scale can be incremented or decremented via the cursor on the Attack format by bumping it out then back into the tactical region within 0.8 seconds on the top/bottom, the same should be possible with the azimuth width on the left/right sides of the tactical region. The left side decrements by one and the right side increments by one. Looks like this one was missed during the original implementation of range scale bumping. Information PM'd to Bignewy. Thanks! azimuth HOTAS bump bug.miz.trk

The reason for this is the existence of the AIM-9X Uplook reticle commanded via aft from Helmet Acq. I don't have the documentation myself to know whether it's correct that even without the 9X you can't go VACQ from HACQ. However I think it's plausible, to prevent the pilot from getting used to going to VACQ from HACQ when he does use the 9X.

Sorry I just realized I didn't cite this... it's stated in the DCS F/A-18 manual. Also have additional source if needed, but devs should know when they see this.

The scan elevation commanded by Vertical Acquisition (VACQ) should be -13 degrees below the aircraft waterline/nose and +46 degrees above it. As shown in the .trk, it is scanning -30 degrees and +30 degrees in game. You can see this by referencing the elevation caret on the Attack format. (Each tick by the elevation caret on the Attack format indicates 10 degrees.) Current behavior - VACQ commands scan elevation +30 degrees and -30 degrees reference the waterline. CORRECT behavior - VACQ should command scan elevation +46 degrees and -13 degrees reference the waterline. Vertical Acq scan volume bug.miz.trk

Well, there does seem to be a bug here in that the possible bar options are being displayed without the cursor over them. I noticed this can happen sometimes. When the cursor is not over the region it should simply display as normally.

The vertical resolution scale of the Az/El format is incorrect, similar to the issue I reported for the Attack format except it's elevation angles and not range obviously. Currently it is referencing the top of the dugout as the top of the elevation scale. The bottom of the dugout should instead be the reference. So for example, if +/- 30 degree elevation scale is set, then the point that is 30 degrees above the horizon should be the very bottom of the dugout, not the top of it as it is now. This is demonstrated in the .trk by scan center position value. When I set the scan center to below the dugout (cursor, correctly, won't let you set it above the dugout), it indicates 26 degrees, whereas if I set it to the bottom of the tactical region itself it indicates -30, correctly. Image attached for demonstration. As per it, note the actual horizon line on the Az/El (0 degree point) needs to be shifted down. Also, the vertical tick marks will have to be adjusted. Another thing is the radar FOV should cut off at the bottom of the dugout, not the top as it does now. TL;DR dugout is considered part of the range-resolved tactical region. It shouldn't be. Entire tactical region needs to be vertically shrunk slightly. AzEl dugout scale bug.miz.trk

The Attack format is currently referencing the bottom of the tactical region to the top of the dugout (angle only trackfile zone) as its range reference. For example, if the maximum range displayed is 80, then the 0nm point is at the bottom of the tactical region and the 80nm point is at the top of the dugout. This is incorrect. The dugout is its own thing, above the range-resolved tactical region. The maximum range scale point should be the BOTTOM of the dugout, and the 0nm point should be the bottom of the tactical region, as it is now. Note also that beyond the correct 80nm point, it shouldn't go to 81, 82, etc. It just ends there. The dugout inherently has no defined range. Vertically, it's completely ambiguous. I attached some pictures to demonstrate. IMPORTANT NOTE: The tick marks on the left and right side of the tactical region need to be re-done as well. They currently represent the incorrect scale. They need to be slightly closer together and adjusted down so as to indicate the correct fractions of the maximum range scale. Also note that the cursor and BRA indication serve as proof that the 80 mile point is indeed being considered as the top of the dugout. In the .trk, the bottom of the dugout indicates about 76 miles. Tactical region dugout bug.miz.trk

This is 100% a bug. The SA, Attack Radar, and Az/El formats are all different views of the same MSI picture. A HAFU represents a single MSI trackfile; it's the same trackfile regardless of which of the 3 MSI formats it's seen on. If the aircraft type is known through PPLI or NCTR data it should be displayed in all the appropriate places (Az/El AND SA). Az/El and SA are two ways of seeing exactly the same information. There's already been an issue where PPLIs aren't properly correlated to radar tracks on the Az/El and Attack but they are on the SA (resulting in different identifications and ranks). Hopefully a rework can be done to make MSI much cleaner (and with that hopefully fixing the array of other inaccuracies/problems in A/A).

By no means am I saying this wouldn't be cool. But, you guys are vastly, vastly, vastly, vastly, and let me say again VASTLY underestimating the workload required for this undertaking. ED is already struggling to get the details right for our current Hornet lot, and even then it's not a perfect model of a single OFP. The amount of big, and small, changes in software alone would be a ginormous undertaking. I'm not discouraging the idea itself. In a perfect world it'd be great. But honestly I don't even know how easy it'd be to get all the documentation for those earlier models anyway. Some might not even be in electronic format. Again, not discouraging a dream, but just want to say that this is far from just remodeling an older engine model.

The RSET option on the Attack format (PB14), in TWS, should clear the L&S designation completely just like it does in RWS. Currently, in TWS, RSET designates the rank 1 as the L&S, effectively making it impossible to have a "nothing is L&S" situation in TWS. However, this should be possible with our Hornet software. The behavior currently modeled for the RSET option represents an older Hornet software. Information PM'd. Thanks! Note: the behavior of designating the priority 1 if no L&S already exists when entering TWS does appear correct. However, once in TWS, the above behavior should apply. Hopefully this should be a simple fix as it should just be how it is now in RWS, but in both RWS/TWS; i.e. one logic for both modes instead different logic for the two. TL;DR-- CURRENT BEHAVIOR: In RWS, RSET clears L&S. In TWS, RSET resets L&S to rank 1 trackfile. INTENDED BEHAVIOR: In RWS, RSET clears L&S. In TWS, reset also clears L&S. RSET L&S bug.miz.trk

What AACQ should do is acquire the L&S, if it exists, and if it doesn't then the priority one trackfile. With no L&S and no AMRAAMs in flight, the priority one trackfile would be the track with the rank number of "1" in the middle of the HAFU. Rank is based on distance, direction, ID etc. If it's doing something else in DCS it's wrong. The priority logic isn't implemented, but it would only really change the logic in the case of an AMRAAM being in flight and an L&S not existing. (Priority = L&S>under AMRAAM attack>DT2>other trackfiles by their rank) Note this is of course assuming the cursor is not over a trackfile. In that case, it should always perform "Fast Acquisition" i.e. STT the trackfile under the cursor, regardless of if that track is the L&S or not. The only time AACQ would not use this logic is in the not yet implemented Velocity Search (VS) mode where trackfile processing doesn't occur. In that case, it would simply lock the hit with the fastest closure rate to you. I would also note the Acq Point Cue in RWS mode is improperly implemented, which is for another report I guess. In RWS, when an L&S exists, the point cue should not be there. This is because the point cue points to the #1 priority trackfile if its HAFU is not displayed. The L&S is automatically #1 priority, so if it exists, the point cue does not. Right now. the point cue simply points to the #1 RANKED track. Recall that rank and priority are different. If the trackfile with a rank of #3 is the L&S, it's still rank 3 and whatever was rank 1 is still rank 1, but the L&S is priority #1. I'll end my slight tangent there lmao.