JF17 WMD7 pod not slewing to waypoints after area tracks OR A2A kills in SLAVE mode

[DroptheHammer]

• Brief introduction
  • In Slave mode, The WMD7 pod used to give up it's current orientation, SPI or otherwise and point at the currently selected waypoint if the "Undesignate" button was pressed (same button as ending a radar lock).  
• Detailed description
  • After an A2A kill, or some area track is established.. the pod no longer returns to waypoints like it used to when a SPI is cleared / undesignated
  • this used to be great, because if I had say a... Pre Planned 1 (WPT36) in my computer.. I could slew the pod to that with undesignate and then check that area for targets.. shoot at something, and then put the pod back on WPT36 by pressing undesignate again.
• How to reproduce
  • Fly to a waypoint, slave the pod to it... attack something not at exactly that waypoint (air or ground) and try to get the pod back to exactly the waypoint you had before via undesignate.
  • The pod will end up putting itself where your last area track was and not your waypoint.
• Attach dcs.log and trk
  • All of my track files for this are larger than 5MB. Not sure how to get such a small one.

Edited June 1, 2022 by DroptheHammer

[uboats]

Because when the POD is in tracking state (hence the SPI designator), the AG radar is put into ground stabilization state and follows the SPI. If the POD breaks track, the AG radar now becomes te priority sensor since it's in ground stabilization state. This would looks like the radar tries to store the SPI location locked by the last sensor. But a change in WPT should reset the SPI back to the selected WPT.

So if you want to resume the previous behavior, put the radar in SP mode in the first place, or switch WPT back and forth when the POD is not tracking, or command S2 Press (unlock) when RDR is SOI.

-- our programmer

[Napillo]

1 hour ago, uboats said:

 the AG radar is put into ground stabilization state and follows the SPI. If the POD breaks track, the AG radar now becomes te priority sensor since it's in ground stabilization state.

that seems like a good thing, so the tpod should try to track to the last ground target... if it worked like that, but if that's the case then, if it loses it, and you fly over the spot, or you switch to a2a... the radar should lose the ground stab, and the tpod should be pointed generally in the direction it was, since there's no soi lock by radar or the tpod

[DroptheHammer]

22 hours ago, uboats said:

Because when the POD is in tracking state (hence the SPI designator), the AG radar is put into ground stabilization state and follows the SPI. If the POD breaks track, the AG radar now becomes te priority sensor since it's in ground stabilization state. This would looks like the radar tries to store the SPI location locked by the last sensor. But a change in WPT should reset the SPI back to the selected WPT.

So if you want to resume the previous behavior, put the radar in SP mode in the first place, or switch WPT back and forth when the POD is not tracking, or command S2 Press (unlock) when RDR is SOI.

-- our programmer

sssooooo...

Why would the Air to air radar make a SPI where the last bandit I splashed crashed in?   And why would that point now be where the A2G Pod wants to reset to?

Also, I practically never use the A2G radar to mark anything...  Does this mean if I want to go back to waypoints, I always need to clear both the pod and the A2G radar even if I only marked with the pod??  In the past I never needed to do this. just SPI designate with the pod, and clear it with undesignate. 

[uboats]

17 hours ago, DroptheHammer said:

sssooooo...

Why would the Air to air radar make a SPI where the last bandit I splashed crashed in?   And why would that point now be where the A2G Pod wants to reset to?

Also, I practically never use the A2G radar to mark anything...  Does this mean if I want to go back to waypoints, I always need to clear both the pod and the A2G radar even if I only marked with the pod??  In the past I never needed to do this. just SPI designate with the pod, and clear it with undesignate. 

Cannot reproduce by our programmer, or wait for next update and check again. Probably some fix internally.