AroOmega

Does anyone know if there is an official way to unmark this as "solved"? It seems clear that the solution was incorrectly marked out of confusion. Do we contact mods or report the solution post? If not, I assume we'll need to re-test the issue and make a duplicate post.

Range does not matter. "Maximum range", "half of the Attk format scale", or anything else is incorrect for C-Scope. Imagine looking through a camera. The boarders of the camera's field of view is your yellow box. If someone asked you "what range is that camera set at?" what would you say? There is no "range" setting that changes a field of view. If you had the moon as a datalink target, it would either be in or out of your field of view just the same as a bird 20 feet from your aircraft. Just to clear up the analogy, "zooming" a camera changes the FOV which is the same as changing the radar bars and scan width not the "range". IIRC you can limit the datalink range of contacts to help declutter the display to show only near targets. In our analogy this would be like blurring the background of your photo--it has zero effect on which objects are in or out of the view.

This is still an active issue in 2.8. Tested during a multiplayer session so I'll go back and get make a smaller trackfile later on. Maybe since this is incorrectly marked as "correct as is" we should submit a new topic? Are you guys noticing it too? Until then just know that you cannot trust your AZ/EL page box elevation--you need your target to be decently inside the box before they are within the radar top/bottom alt numbers.

Is it possible to get the "correct as is" tag removed? @BIGNEWY

If that's correct that's news to me. I thought the page showed azimuth and elevation (hence the name "AZ/EL")--it's a c-scope right? So if a yellow dot is drawn showing what my radar is pointing at, it will be pointing the same no matter what distance the target is at. Here's a visual. All targets in the yellow should be between the highest and lowest scan lines. Distance should have no effect on my visualization of the box. If you look at the images posted by OP, the target (angels 6) is outside of the scan zone (angels 12-68) but still shown within the box. Am I missing something? OP didn't describe it well and I think some replies just missed the numbers on the radar page?

Thanks for the reply @BIGNEWY! It means a lot I would like to advocate for this to be considered an existing bug of the AZ/EL page instead of a new feature of MSI. The reason I think this should be considered a bug is that it's already be implemented as described in the Hornet Early Access guide. The guide calls out datalink tracks, the selection works as expected, the boxing works as expected, the AZ/EL page "knows" it's slaved to that target (even DL targets). The only issue is the that the TPOD movement to boresight. Unlike MSI features that are yet to exist, this one is nearly fully functional and does successfully slave to the DL target just fails to point the TPOD in the right direction. Sorry if I'm describing it poorly, the subtle detail I'm trying to highlight with is that the MSI part seems to be working already. I know MSI includes work that crosses over lots of Hornet systems and sensors. This specific issue seems to be different from those wished-for items in it's currently implemented and documented. MSI features like LOS tracks or generating tracks from TPOD points might not effect this since the AZ/EL has working support for slaving to DL tracks. My hope is that this is a bug of an already implemented behavior and won't fall under the MSI epic, or be prioritized with MSI features (and I'm hopeful this might be a low-hanging fruit bug) Thanks for the time! Have a good day

Checked again in the current open beta version as of 10/19/2022 and it's still an issue. Same behavior where it shows SLAVE boxed, slaves the FLIR incorrectly to boresight and properly resumes the track once your radar picks up the one you've already slaved the FLIR on. Would it be helpful if I uploaded a shorter track? I know the first one mainly shows it best near the end of the track.

The F/A-18C Early Access Guide state on page 387 the following behavior for FLIR and AZ/EL page: This behavior works as described when the tracks being "TDC released" on are onboard tracks (visible on your radar). Attempting to perform a "TDC release" on an offboard track still partially works; doing so boxes the "SLAVE" text and the track is "remembered". However, the TPOD does not track properly. If the track is picked up by radar and becomes an onboard track, the TPOD snaps to the correct point and behaves. This behavior can be seen by switching a track back and forth from onboard and offboard via radar slew or silencing the radar. This behavior appears regardless of when the track is "TDC released" meaning you can start with either an onboard or offboard track and the same result is seen. The attached track file shows the behavior (PG map, ATFLIR, DCS version 2.7.18.30348) In the track you will see multiple AZ/EL page "TDC release" actions onto both onboard and offboard tracks. Behavior of FLIR is shown to snap on and off tracks as they switch from onboard to offboard and back. Notice the "SLAVE" text boxed when a track is "remembered" and has been properly "TDC released" on. EDIT: Just a note of why this feature, when working, is so cool: Using the FLIR pod in this way is almost like having an IRST but with the "S" replaced with your DL. The FLIR tracked air functionally works for a lot of stuff like AIM-9 aiming, keeping a DT2 track while in STT, etc. You can use datalink and FLIR to be sneaky and track targets without turning on your radar, maintain tracks when the target drops off radar in a notch, or launch a FOX-1 while keeping an eye on his wingman via the DT2 track. flir_azel_page_not_slaving_to_donor_tracks_when_offboard.trk