Jak525

Yes, Wide Acq is either caged or uncaged. TDC depress to uncage. In caged WACQ there will be no "+" shape. Scan volume is rotation stabilized but will point where the nose is with regard to pitch. Uncaged WACQ has a plus shape and is totally stabilized and slewable. Pitching the jet won't point the scan. Rather, it will be slewable and horizon stabilized. And again in both caged and uncaged WACQ the scan is roll stabilized, as represented by the rectangle on the HUD.

Here is a flow chart I made a while ago of how the Hornet should return to search. (Excuse lack of prettiness it was some free app I got on my phone lol). Hope this can alleviate any confusion. RTS (Undesignate button, hitting "RTS" on the screen etc) should never go to any of the ACM search modes. To go back to any of them from STT, you just use the castle switch. But RTS only ever takes you back to RWS/TWS.

The "HMD" option on the FLIR and Az/El format is located along the L+S and BST options. It's one of the FLIR pointed modes. Basically it just slaves the FLIR LOS to the HMD LOS. From there I guess you could try visually autotracking a target or something. Seems pretty useless. Of course I wouldn't oppose implementing it for the hell of it since it is quite simple. Anyway Az/El and HMD have nothing to do with each other. The HMD option is just there on the Az/El because the FLIR slave modes are copy pasted onto the Az/El, because the Az/El can be used to cue the FLIR in A/A. This is very much a FLIR function that happens to tie slightly into the Az/El interface.

I haven't analyzed this report in particular but do note that if the throttles are advanced past a certain angle with WonW the aircraft forces NAV master mode.

It's just missing/not done yet. It should be able to be seen from the TGT DATA format. I think this would be best addressed once the MSI system is redone, so that PPLIs are harmonized as one in the first place, without separate targets with potentially different associated variables on the three MSI formats.

Also note even if there was no INS integration with the actual RWR, the bearings are sent to the MC so it could easily "post process" them to stabilize them with the INS data. Every sensor passes thru the MC to actually put its data to use.

Lol so funny reason behind that. The reason that's there is because ED modeled a Litening off of an avionics build where the ACM condition didn't exist. ACM modes existed like Boresight, WACQ, etc. But there wasn't any ACM condition system for the Castle switch. The logic was, with TDC assigned to the Radar in AA master mode, castle up for BST, left WACQ, aft VACQ. Assigning TDC to the left DDI would therefore be impossible. As such, the TDC button is put on the FLIR format so you can assign TDC to the FLIR. This is obsolete with the invention of the ACM condition which clearly separates when the Castle switch is doing ACM selection functions or "top level" functions like assigning TDC priority and whatnot.

Yeah totally wrong lol… Unless you're in LnS slave (not Autotrack), in which case silencing the Radar would delete the track (but not immediately, the target HAFU flashes for a bit first) - and thus, the FLIR would lose it since it's not in track, but is just pointed by the computer to that LOS Just as a note, despite it working practically better at the moment: Litening is modeled after old avionics that predate MSI. Hence why the RRSLV options and stuff are on the Litening; those get removed with MSI.

It's just what I described, nothing crazy but quite handy. All that's missing in DCS is the ability to autotrack from azel. The super cool, missing element of MSI is the FLIR's contribution. So if you have the FLIR in Autotrack on a target, it creates an angle only HAFU; looks normal on the Az/El, and in the dugout on the Attack and SA. You could make it the L&S, and, very importantly, directly Radar STT it like any other track. Or just simply cue the scan volume at that azimuth and elevation on the AzEl. This is why there is no direct Radar to FLIR slave mode. It's unnecessary with MSI.

Expanding on what Harker said, yeah, it's all real clunky without proper MSI. To transition to a Radar track to a FLIR-only track what you should be able to do is simply go on the Az/El FLIR sublevel, cursor over a HAFU, and castle toward Az/El. This should command the FLIR into Autotrack. From there a quick double Castle forward should go to EMCON, shutting off the Radar but the FLIR is obviously unaffected as a passive sensor. You could also select SIL on the Attack format. The HAFU remains there, since the FLIR (in Autotrack) contributes to MSI. Although no range or altitude data. A few other methods exist too; e.g. designate a Radar trackfile as the L&S, go to FLIR L+S slave, then command Autotrack from the FLIR format. Alternatively you can TDC depress over empty space on the Az/El FLIR format, slew over a track, and then release which commands the FLIR to be slaved to that trackfile's LOS. From there you could go to the FLIR format and Autotrack. Then once ultimately in Autotrack you can SILence the Radar or go into full EMCON mode to shut off other radio emitters. I feel like the latter two methods should work now actually...

No need to be dramatic Topper. But Bignewy, I'll message you.

Threat filtering is a pretty huge trade off because of the lack of MSI Radar trackfile processing in VS. Best off just looking at the trackfile ranks (also a bit wrong now). Detection range though would be a consideration. It's largely quite useless from what I've heard from real world guys. That said, it's a quite straightforward mode. I don't care if they don't do it till 2025 but I see no reason to say "never". It IS a Radar mode of the APG-65/73 in the F/A-18 in any given OFP. It's sort of like modeling the air conditioning fan in the Hind...

No problem. No, there is no timeline. Just cross your fingers and pray or something

Multi-Source Integration is totally different than the "MSI" toggle option on the ATTK>DATA sublevel. MSI trackfiles include all Radar, FLIR, and Link 16,trackfiles. When you hear Radar it means onboard Radar because tracks from the Link can be from any source, in the end youre just receiving trackfile data thru the net from another aircraft/entity with sensors, doesn't matter if it's from your friend's Radar or anything else. You are supposed to have (emphasis on supposed to; DCS is totally wrong at the moment) all MSI trackfiles displayed on the Attack, Az/El, and SA pretty much identically. MSI tracks are sensor-fuzed targets using the available sources. Now with regard to display there is a very unique scenario in RWS only on the Attack format. Note this is only regarding display; the tracks still exist the same way, and are on the SA/AzEl. Basically, in RWS, the goal on the Attack is to display a mostly decluttered picture of raw hits (bricks) and hide trackfiles. The bricks represent raw returns from your Radar. They're not MSI tracks. The Radar target information (which is represented visually by the bricks) is processed into MSI targets. They may be Radar-only or be correlated with other sources that the computer thinks are seeing the same target. E.g. you and a F/F donor are painting the same plane in the sky. MSI didn't always exist. Early on the Hornet only had Radar trackfiles. As such, RWS was simple. Bricks were displayed unless you designate a track as the L&S by cycling Undesignate button, in which case the trackfile is shown. Here comes in the LTWS feature. LTWS is not a mode, but merely a display option. LTWS allows you to cursor over a raw hit and display the hidden trackfile without designating it. Basically a "preview" feature. That's all fine and dandy, right? In a world without MSI, we only have Radar trackfiles so we can assume they exist and see where they are by seeing the raw bricks. Problem arises with MSI trackfiles. Imagine you have a F/F-only trackfile. How would you know it's there? There's no raw hits for something that isn't seen by the Radar. Thus comes the solution: forcibly display any MSI trackfile with any contributor that isn't the Radar. Even if it has Radar, if it has other contribution it's also shown. The only truly hidden tracks are Radar-only. This logic, necessitated by MSI, can be toggled by the "MSI" option. So that's all that does. I really didn't anticipate this post to be as long as it turned out to be...

Implementation in-game is totally incorrect. Wait for the eventual reworking of MSI. You are correct about LTWS. For the MSI option, confusingly it is not actually supposed to toggle MSI. If you unbox MSI, the Az/El and SA formats are unchanged, and the TWS Attack format doesn't change. The only difference is in the RWS Attack. It, similar to LTWS, "unveils" non-radar trackfiles automatically (those contributed to by FF, SURV, PPLI, your FLIR in track, etc). So with MSI boxed the only hidden trackfiles are those with solely radar contribution. Reason for the MSI option is since RWS is mainly bricks on the Attack page, which are raw radar returns (NOT trackfiles), you want an indication of non-radar MSI tracks' existence.

Yeah this is totally incorrect, I don't know why ED hasn't fixed it yet.

The opposite. The jet doesn't even know if it's lost communications with the AMRAAM since it's a one way datalink anyway. LOST has to do with the missile being kinematically lost and has everything to do with Rmax. It is however useless in DCS due to the incorrect implementation. It is not freezing parameters at launch but rather indicating Lost as a function of the current kinematics between the jet and the target, not the missile in-flight and the target. In other words it's providing cuing for the missile on the rail. Furthermore LOST should only be a quick flash. After a few seconds the straight line (SL) counter should be displayed for the missile. Totally ignore the Lost cue right now, because it is not representative at all of whether the missile in flight has been lost.

This is a fundamental principle of the Hornet avionics, I'm sure the devs will understand. When a sensor is in track, it's driving the designation with its data. E.g. FLIR in Autotrack or Scene track, Radar in FTT (TRACK), LST in track. If a stabilized designation has merely been created out there via the Radar format in search or the FLIR format in regular pointed mode (not Scene or Autotrack), then it's not tracking and the designation isn't tied to any one single sensor. This is the reason you see RDR or FLIR etc in the HUD when in track but not if for example you simply make a designation on the Radar format in MAP mode. If the Radar is in track the FLIR should be following the designation LOS that is driven by the Radar. If the FLIR is commanded to track then the Radar exits track and the designation is now driven by the FLIR. Think of it as a soccer ball. Anyone can kick it around (no sensors tracking) until someone picks it up (sensor goes into track). At that point it's tied to that persons until someone else grabs it instead. @Mo410 can corroborate.

It's a known issue. Memory and interleaved PRF are also totally different functions. Anyway this is mainly not the Radar losing things but the avionics not mainteining the trackfiles in the correct way.

The lock lines are only for the SA, not Attack. A missing piece of the SA is the blanking around the STEP box also. It should occlude any trackfiles inside the box shape, other than the one that's stepped to, so you can see it a lot more decluttered. As mentioned EXPand works too. SA and Attack are hard to cross reference right now due to the funky and wrong MSI logic right now, resulting in tracks having different ranks/IDs, ultimately resulting in different looking HAFUs for the same target on both displays. No, lock as in acquisition into STT can only be done from the Attack or Az/El. However L&S/DT2 designation is supposed to be doable from the SA.

Spotlight should be available outside of A/A, that's a bug.

In this scenario, you would simply hit Undesignate/RTS (return to search), which'd exit both STT and ACM, and then hit the SIL option. There is no way to go straight from ACM, nor STT, to SIL. That's just how it is. If you REALLY need to go silent right then and there you could Castle forward twice quickly to go into EMission CONtrol mode, which shuts the radar off and anything else sending out radio waves.

Correct, it's option C. Obviously it makes zero sense for the jet to enter ACM from SILent, stay in SIL, and have no button to exit SIL from there. Just common sense. Anyway, commanding ACM from SIL is the equivalent of unboxing "SIL" (plus it commands ACM, obviously).

Commanding ACM from SILent should exit SIL and go to ACM. No way to enter SIL directly from ACM since yes, the "ACM" box replaces it.

For how bricks look - Real pictures of the jet and pilot input. Design flaw? I mean youre free to critique the design of the real jet, but I'm telling you that's how it is, and if real pilots had a problem with it... I'm going to go off on a limb and guess it would have been changed. It's been reported yes. It'd apply to both TWS and RWS. RWS processes trackfiles in an identical manner to TWS. The difference is that RWS intentionally hides some tracks on the Attack format - the logic for which is wrong in DCS right now. And also, RWS allows for a huge volume whereas TWS artificial limits it. TWS has Auto/Bias scan centering, SCAN RAID, EXPand, etc. Both RWS and TWS in the Hornet are what would be traditionally called "TWS".