Reimplement the code reverted in 35f5f3eb3758dc09d3a0ae3bffccd033245abe51

[TaranDahl]

Stop immediately if the target enters the range during ApproachTarget

• In vanilla, the ApproachTarget will simply exit and do nothing if the target is in range. This will cause your units to approach the target unnecessarily.
  • Now you can change this behavior by the following flag.
  • The setting can be customized per techno type; if not set on a type, the global setting is used as the fallback.
  • AttackMove.StopWhenTargetAcquired is read as a compatibility alias for ApproachTarget.StopWhenInRange (in both [General] and techno type sections).

In rulesmd.ini:

[General]
ApproachTarget.StopWhenInRange=false  ; boolean

[SOMETECHNO]
ApproachTarget.StopWhenInRange=       ; boolean, default to the same key in [General]

Keep pursuing the target during ApproachTarget

• Now you can make a unit approach its target with the target itself as the destination, just like ZEP, instead of a point on the arc around the target whose radius is the unit's own weapon range.
  • If ApproachTarget.StopWhenInRange is set to true, the unit will stop as soon as the target enters its range and will not chase it further.
  • AttackMove.PursuitTarget is read as a compatibility alias for ApproachTarget.PursuitTarget.

In rulesmd.ini:

[SOMETECHNO]                   ; TechnoType
ApproachTarget.PursuitTarget=  ; boolean, default to false

[github-actions]

Nightly build for this pull request:

• compiled-dll-801fb66805353fcc08755992f9cc808822613455.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[TaranDahl]

The AttackMove.StopWhenTargetAcquired has been deprecated because it was implemented in an incorrect way. It should be ApproachTarget instead of AttackMove that needs to be modified. It has now been replaced by ApproachTarget.StopWhenInRange. The prerequisite for it to take full effect is #2084.

The AttackMove.PursuitTarget has been deprecated because it was implemented in an incorrect way. It should be InAttackMoveKeepRange (implemented by #2081) and ApproachTarget (implemented by #1998) that need to be modified.

[Coronia]

given there were quite a lot of controversial for our previous tag renaming (such as new Trajectory and the recent major renaming), I think we should still stick to the principal of no tag name change unless necessary. For this PR I think we don't have to depreciate those AttackMove tag, could just redirect their implementaion to the new one.

[TaranDahl]

deprecated because it was implemented in an incorrect way

I don't think we should keep something that is incorrect. This is not a simple tag renaming. They are removed because the function itself is incorrect.

[TaranDahl]

Bounty: 10 CNY for the 1st reviewer who gives valid review

[DeathFishAtEase]

Changelog entry position error

[DeathFishAtEase]

I see that it has already added the Tested label and is not a draft, so should this PR already be in a completed state?

I don't think we should keep something that is incorrect. This is not a simple tag renaming. They are removed because the function itself is incorrect.

The documentation for the discarded INI flag and its related content does not seem to have been removed yet, which should also be part of the pending work for this PR, because I see that they have already been removed in the changes to the source code.

[Coronia]

seems not working as great as before. Sometime the unit won't stop when facing a target in attack move

[TaranDahl]

Can you post a gif?

[fagonghaiwo]

old
[General]
;ApproachTarget.StopWhenInRange=1
AttackMove.StopWhenTargetAcquired=1

new
[General]
ApproachTarget.StopWhenInRange=1
;AttackMove.StopWhenTargetAcquired=1

doesnt work

[TaranDahl]

This is not an issue with this feature. It is a problem with task switching. Hover has a similar issue to Jumpjet: their IsMovingNow is handled incorrectly, which causes incorrect evaluation of ReadyToNextMission. Even when AttackMove detects a target and queues an Attack mission, it cannot switch over.

Optional solutions:

1. Simply revert to the old code. I do not know why, but since it works in practice, it works. However, the old implementation is essentially piling more garbage onto a garbage heap, because the root cause of the failure to stop properly comes from ApproachTarget rather than AttackMove. Other tasks that need to call ApproachTarget will still be problematic.
2. Exclude Hover in FootClass_ReadyToNextMission_MovingCheck. In fact, I currently believe that the IsMovingNow check is unnecessary for any Locomotor. Side‑effects are unknown, though.
3. (Recommended) Ignore the Hover shit, push forward the merge of PR2042, and then replace all Hover instances with AdvancedDrive.Hover.

[TaranDahl]

@Coronia The choice is in your hands.

[Coronia]

First of all, I don't think the problem should be left unresolved even if AdvancedDrive is added. Hover is something that every mod has been used for age so it's not even feasible to replace them in a wide scale. Whatever AdvancedDrive did shouldn't be considered in the current topic

As of the problem itself, I think tweaking FootClass_ReadyToNextMission_MovingCheck might be an acceptable solution since this is the root cause. But if we want to avoid potential side effect, maybe we could just do some special handling to Hover for ApproachTarget's case alone? In worst case we can just reuse the previous codes for Hover alone since it has proven to work

In any case, if we can't find a proper solution then I would still suggest reverting the old implementation for now

[Coronia]

so far seems to be fine in testing, perhaps @Metadorius could take a look before the merge

[Coronia]

there's still one remaining thing to optimize: using locomotion_cast to merely check if it's jumpjet or hover type is a little bit costy. I'll make a variable to cache it for such scenario, but that's not part of this PR anyway. Merge it first so that I can proceed the latter work