Jak525

The depiction of hits in that diagram is simply wrong. Diagrams are often not super accurate. The age out should not be a linear fade out though so that's a bit incorrect right now unless they did actually do this right, I haven't checked. There should only be full, 1/2 intensity, and 1/4 intensity. Depending on age out it's different. 2 second age out for example the bricks never dim to 1/2 or 1/4. It's just regular brick then gone. With 32 second for example though you'd see it transitioning from full, to 1/2, to 1/4 intensity throughout time. Yes it is time based in the Hornet. There is no question about this. The advantage is that you can see where an airplane was a given amount of time ago. E.g. with a 16 second age out you know the "tail end" of the trail is where the plane was 16 seconds ago. Halfway through the trail about 8. A frame based storage is way different because depending on your scan volume the time a frame takes can vary greatly. Both work obviously as it's been implemented like that in other airplanes' avionics. But it's merely a design decision. That's how it works in the F/A-18. The reason it's so bad to use is because trackfiles are completely wrong right now. If they worked right, this'd all make a ton more sense and be quite intuitive. I am not one to say DCS is correct as is when it isn't. In fact if you look through the vast majority of my posts around here are explaining how things are wrong, lol. The brick aging, however, trackfiles aside, is correct. It's just overshadowed by the incorrectness of trackfiles.

I think I understand you now. The F/A-18 simply does not store bricks based on the radar frames. It's only time based. Yes, it stores hits from previous frames, but that's only coincidental. It stores the hits purely as a function of time. If you want a smaller trail, set it to something like two seconds. That should produce only one hit per trackfile. HOWEVER, the problem here is that the trackfiles are currently tied incorrectly to the brick storage time and therefore it's incredibly impractical to use the radar with a low hit storage time. What you should be able to do is set the storage to like 2 seconds and therefore have it very decluttered, and the trackfiles are unaffected and stay for longer. They should only start deleting when missed in a frame. (In fact, also, TWS is supposed to have a fixed hit storage of 2 seconds; furthermore you can hide hits by unboxing "HITS"). TL;DR the raw hits themselves are correct. The problem is the trackfiles. Please tell me if you think I'm still misunderstanding you though cause maybe I'm missing something here.

The raw hit storage is based on time, not frames. The extremely important issue is that the raw hit storage time is tied to how long trackfiles are maintained, which is entirely different and unrelated. This should be completely independent from the raw hit age out. That's simply a decluttering function, and should have no impact on the trackfiles. A trackfile should instead go into memory on a "missed frame" type logic, eventually going into a flashing Memory phase and then deleting entirely. It has nothing to do with the age out time. A trackfile will delete just as slow or fast with a 2 second time vs. a 32 second age out time, because they have no connection. Basically, once the Radar has missed a trackfile in the scan frame, which will happen sooner for a small volume and larger for a bigger volume (since the duration of time it takes the radar to complete the full scan is dependent on size aka azimuth/bar), it declares memory on that radar trackfile. It will flash for a bit and then the trackfile (HAFU symbol) is totally deleted. The trackfile memory also plays into MSI, also missing a ton in DCS right now. But basically, if you have a trackfile with just radar contribution, then the radar going into memory and deleting means the full trackfile is deleted. If, however, you had Radar and Fighter/Fighter (Link 16) contribution to a single track, then merely the radar's sensor contribution to the trackfile will be deleted, but the trackfile itself remains assuming the other contributor(s) are intact.

The whole point of the ACM condition is that the Castle switch is reconfigured for selecting the ACM modes. There is no other function the Castle switch will do. Ignore the DCS manual, it's often wrong or poorly explained. That's the whole reason there is an "ACM condition." There is no bug here. To be clear, when 1) the FLIR format is on the RDDI and 2) you are in the ACM condition, Castle right should not affect the FLIR format, nor anything else except commanding the ACM acquisition modes.

There can also be an L there, for laser, but not modeled.

Yes, no cursor is correct when in ACM EXCEPT STT. The ACM button when in ACM except STT (e.g. WACQ, HAVQ) should exit ACM entirely and go back to RWS/TWS/VS. In STT as we're talking about, it exits ACM but remains in STT.

Wait, you can TDC depress over the ACM option and it exits ACM but stays in STT? Awesome that's good they implemented that. Just need to fix the pushbutton method then.

If you're in TWS the RAID switch does SCAN RAID and if you're in STT the RAID switch does STT RAID (aka just RAID or SAM). One Look RAID is a "passive" RAID not involving the HOTAS switch.

Yeah fair enough. I'm pretty sure the RAID switch is not toggling EXPand in game though (nor should it).

Good report. This is important so you can return the Castle switch to non-ACM functionality without leaving STT via return to search. (Only note: this wouldn't work with the Gun selected. In that case you're always in ACM, no way out.)

This behavior is correct. The cursor stows as positive feedback of the option being selected. One thing I'd note is the cursor should be able to be slewee a lot lot faster than it can be in DCS.

Yep, so to slave the Radar to FLIR, you'd just acquire it like any other trackfile on the Az/El or Attack. You could also make it the L&S and so on. The reason there is no dedicate "Radar-FLIR slave mode" is because of this. There's no need for it with MSI.

Laser is not used for ranging in AA. The range is either from FLIR passive ranging or the FLIR Autotrack target merely being correlated to a Radar target and thus fused into a single MSI trackfile, and the range data would be from the Radar. With no passive range or another range contributor then the trackfile for the FLIR target would be angle-only without range. That said, yes, does appear the code is still changeable in AA. Paging @Mo410

Correct. The FLIR is only in air to air mode when you're in A/A master mode.

Nice work here. Although wrongly implemented in DCS right now if you want to reflect what it should be, the example of L&S stepping via Undesignate should be this, since the rank should not be changed (just hidden by the star). ★ 1 2 -> 3★ 2 -> 3 1★ Not: ★ 1 2 ->2★ 1 Also RAID switch only toggles TWS SCAN RAID / STT RAID not EXPand. Again nice work

I haven't tested if it works properly in game but you should be able to press the boxed ACM pushbutton (PB6, RDR/ATTK format if I recall) to exit ACM but stay in STT. But yes the logic of staying in the ACM condition after acquiring a target into STT from an ACM mode of acquisition (e.g. WACQ) is correct. An alternate method if you don't want tk exit ACM would be to merely box L+S slave via pushbutton on the FLIR (or Az/El) format. Of course this isn't as good as an Autotrack but since you're in STT on the L&S it should be pretty good. For scenario 2, the FLIR is in A/G mode while in NAV or AG master mode. What's happening it sounds like is you actually designated the aircraft as a ground target designation. The changes on the HSI are due to the target being designated/steered to. To employ the FLIR in air to air you need to be in A/A master mode.

Behavior is correct. The Hornet remains in ACM condition while in STT having entered STT from an ACM mode; hence "ACM" still being boxed. There is no need to assign FLIR TDC priority to make it slave to the L&S I'd note also. That being said the boxed "ACM" button on the Attack format in STT should be able to be pressed to exit the ACM condition but stay in STT. Pressing "ACM" in an acquisition mode like WACQ will exit it entirely, but for STT, it stays in STT while exiting ACM. This is the solution to your issue if you wanted to use the castle switch to assign TDC to the FLIR. The caveat would be that there is no way to do this when the Gun is selected as in that scenario the ACM condition is not exitable. What you describe here is not a bug. However there is a separate bug here if the behavior I mentioned doesn't work. I'd give it a test.

We're talking about when you take the cursor all the way to the edge of the screen. Near the border on the tactical region side, yes, good point. But toward the edge of the DDI itself it's not triggering. See the 3rd screenshot he posted.

Noticed this. Yep, definitely needs a tweak.

You're right. Need a track here. But in the end I think even the additional bug ties into MSI, and any fix now would just be a bandage before the rework.

This is related to the issue/need to rework the Multi Source Integration (MSI) trackfiles entirely. I'd consider it part of that overall bug. But yes, it is a bug.

Exactly what Bankler said. Here's a way of looking at it: You're making a pasta according to a recipe. You add sausages, which were not in the recipe. You are told it shouldn't have sausages. A few chefs, who were there when the recipe was made, even say it shouldn't have sausage. It wouldn't make sense to say they need specific evidence stating it should not have sausage. Rather, no sausage should be the default until proven otherwise, not the opposite.

Yeah, it's pretty obvious the max speed should be wayyyy quicker.

Yup, this is indeed correct as is. The one exception is the ACTIVE option in SILent mode. It would be easier if the TDC had a better slew rate. The cursor should be able to move a lot faster.

They don't remember like the F-16 I believe does. For example if you had the FLIR up in A/G and switch to A/A the FLIR should stay there. If you then open the Stores format in AA, and switch back to AG, the Stores remains on the left DDI. It doesn't remember the format per master mode, rather it just does not change it. Exception applies to RDDI which invokes the Radar/Attack format on entering AA. Yeah, 20X was 09 or something? It was the first merged OFP, hence the X. X means Super Hornet and Legacy. C means Legacy only and E means Super Hornet only. Of course the C and E OFPs were largely similar if not identical. Anyways, but with "X" they formally merged them. I think generally as modern as possible should be the mantra if given a choice, within the 2000s timeframe.