VKing

Am I understanding correctly that you are flying by lining the steering line up with the gun cross? If so, then that's your problem. The gun cross at the top of the hud is irrelevant; a CCRP attack is flown by putting the FPM on the steering line. It doesn't matter if the line is left or right in the HUD, the computer will compensate for drift as long as the FPM is lined up with the steering line. For a strong crosswind, the correct lineup might look something like in this screenshot.

I missed this part. That is indeed a bug.

This is the same behaviour as before (or at least I believe it's currently correct). It starts HUD/HMCS-stabilized, then the first TMS up action changes to ground-stabilized where you can slew it around to fine-tune it, then the second TMS up action saves the markpoint.

This is an example 4-ship setup where the flight lead can get the distance to his second element, or swap channel X for Y to get the distance to the wingman without having to change any numbers. ETA: The distances are just examples, not any kind of TACAN limits.

My guess is that they don't want to accidentally confuse - or worse, merge - information about the datalinks in the DCS game and any sort of acual Link 16 or VMF simulation they might be doing in their defence products. So they call it TNDL and SMDL instead of Link 16 and VMF, so that when someone in the company says Link 16, nobody thinks they're talking about DCS.

I believe the problem in this thread is an expression of the bug that causes the HARMs to go active before they are in their terminal phase. If the HARM does no go active before the terminal dive, you won't get HARMs that miss by the width of the map if the radar turns back off again.

Here's a track showing that the underlying issue still exists in MT 2.8.8.43704.

Retest on MT 2.8.8.43704 HARM_EOM_Tracking_bug_F-16_MT-2.8.8.43704.trk

@BIGNEWY The track I posted has the bug in it. I don't understand how the replay thing works that you can't replay it; do you know if there's a way of getting partly through the replay and restarting the track recording or something like that?

I have the same error happening in both MT and ST exes.

It crashes in the Single-thread exe as well.

Due to the randomness of the bug, I haven't been able to get a shorter track, but playback works fine on my end, so I've gotten a recording showing what it looks like. (The IHADSS decided to stick to my actual head as I was recording rather than the head position in the track, so that's why the symbology goes weird) Every time George goes "Ah.. Aircraft's Armed" is a down command to cease, while any up commands to slave are ignored. When I go to the CPG seat, I only ever switch to HMD as sight, the reset to TADS is automatic. Same with slaving, I only ever initiate the slave, all unslaving is automatic.

I'd call that in itself somewhat abnormal, as I didn't crash while recording the tracks.

Apache_George_CPG_Arm-Slave_bug_full.trk Managed to get a track of the full bug. @Lord Vader Can confirm ump104's statement that switching to the CPG seat and changing acq source to PHS lets you use George again, albeit slightly broken.

Apache_George_CPG_Arm-Slave_bug_partial.trk Here's a track in SP that shows part of what I saw when I had the bug previously. I don't know if this is a fully separate bug or not from George not safing the aircraft and refusing to slave again. Towards the end of the track, when commanding George to disengage, instead of slaving the TADS to FXD, he slaves it for a short while and then deslaves, leaving the TADS space stabilized instead of fixed. What's different in this instance is that George safed the aircraft and I could arm/disarm it at will, and George accepted the slave command again after not slaving the TADS back to FXD.