How are offsets supposed to work?

[LastRifleRound]

It's my understanding from the TACMAN that offsets in the Hornet should work like this:

Let's say we set up a waypoint on a prominent feature, like a radio tower. Let's say our offset will be a target that is a known bearing and distance from that tower. Let's say by drift, the waypoint is displaced a bit. When I have the tower in sight, I designate the waypoint, then slew either the HUD or sensor over the tower. I hit offset, I should be looking at the target.

Instead, any slewing or designating I do on the waypoint changes the offset to what I designated, and no offset is applied when hitting offset.

Am I wrong here? The current implementation makes no sense.

There was this comment in the November update, but it doesn't seem to work.

Fixed: OAP designation is incorrect with CCRP -  fixed calculating relative TD OAP position

[Foka]

What you are describing is INS drift correction. I don't know if it works, I only did it on TACAN position.

Offset has nothing to do with correcting waypoint position nor INS drift.

Like in your example - you have a waypoint on the tower, you know your target is 2 nm at 200 degrees, you set offset with that data and now offset is pointing at your target.

[LastRifleRound]

On 3/14/2024 at 8:04 AM, Foka said:

What you are describing is INS drift correction. I don't know if it works, I only did it on TACAN position.

Offset has nothing to do with correcting waypoint position nor INS drift.

Like in your example - you have a waypoint on the tower, you know your target is 2 nm at 200 degrees, you set offset with that data and now offset is pointing at your target.

That's part of what makes what I'm decribing necessary, but it is not itself what I am describing.

Also offsets are DEFINITELY involved with INS drift. Please read Hornet tacman, see W-OF function in Harrier tacman, watch linked videos in A-7 forum, or reference dash manual for the Viper for OAP/VRP/VIP if you don't understand.

Could also be a scenario where you have a great relative reference but poor absolute coordinate positioning.

Edited March 16 by LastRifleRound

[oldcrusty]

I used the OAP/OS in my mission and yeah... there were issues. Not exactly the scenario that LRR described but definitely related.  I used HMD to designate my JTAC's position (OAP) and refined on TPOD. I used BRA to designate O/S.  This wouldn't work until I marked OAP as Mark1.  From there I created O/S with specified elevation (well, certain HSI map features are not modeled yet).  It showed correctly on FLIR.  Just some minor refinements on FLIR. Splashed the targets with IR Mavs.  Turned around for a second pass avoiding any violent maneuvering since this can cause the designation to go bonkers (in DCS).  All looked good but whenever I switched between OAP and O/S on HSI, the FLIR stayed locked on O/S wouldn't 'fuse' with Hornet's mission computer until I dropped FLIR's lock with the 'pinky'.  Then, after trying to re-designate the O/S,  the elevation was acting funny. It was showing 176 ft.  The programmed O/S elevation was 580 ft.  580 ft. is roughly equal to 176 m... could be some bug there.

 

[LastRifleRound]

Yeah it's weird. When you give a waypoint an O/S it becomes an OAP, because you are supposed to be aiming at it. When you have the OAP designated, and then refine it, say with TPOD and designating with TPOD, hitting O/S should apply the offset to that new, designated position. Instead, designating the OAP, then refining the aim point, then hitting O/S makes the O/S overwritten with the designation, instead of applying the O/S to the designation.

Edited March 19 by LastRifleRound

[oldcrusty]

1 hour ago, LastRifleRound said:

Yeah it's weird. When you give a waypoint an O/S it becomes an OAP, because you are supposed to be aiming at it. When you have the OAP designated, and then refine it, say with TPOD and designating with TPOD, hitting O/S should apply the offset to that new, designated position. Instead, designating the OAP, then refining the aim point, then hitting O/S makes the O/S overwritten with the designation, instead of applying the O/S to the designation.

 

Was this in a brand new mission or an older one made in previous builds?  (I don't know if that matters).  I did my tests using my own simple mission made in current build.  The reason I'm asking is that in one of my tests I did exactly what you described:  wpt=OAP  >>  O/S using bearing, range and elevation  and  all worked fine... on the first pass.  

EDIT:  Oh wait, let me correct my post a little.  When I tested my WPT as OAP I didn't make any corrections before designating it as OAP.  If I did I suspect I'd have to mark my new refined position and use "Mark #' for OAP.  That's what I had to do in my vid converting a visual designation to a Mark. You're right.

Edited March 19 by oldcrusty

[LastRifleRound]

1 hour ago, oldcrusty said:

Was this in a brand new mission or an older one made in previous builds?  (I don't know if that matters).  I did my tests using my own simple mission made in current build.  The reason I'm asking is that in one of my tests I did exactly what you described:  wpt=OAP  >>  O/S using bearing, range and elevation  and  all worked fine... on the first pass.  

EDIT:  Oh wait, let me correct my post a little.  When I tested my WPT as OAP I didn't make any corrections before designating it as OAP.  If I did I suspect I'd have to mark my new refined position and use "Mark #' for OAP.  That's what I had to do in my vid converting a visual designation to a Mark. You're right.

 

Yup, we're on the same page here. You shouldn't have to make a mark point at the designation, then set the O/S on that.

In your example, you should be able to apply the O/S to the waypoint, designate and refine on the JTAC, then hit O/S and be staring at the target with no other steps needed.