Fix the bug where stationary vehicles would also block movement caused by external factors

[DeathFishAtEase]

The movement caused by external factors such as a locomotor warhead.

[phoboscn-bot]

To Chinese users:
This pull request has been mentioned on Phobos CN. There might be relevant details there:

致中文用户：
此拉取请求已在 Phobos CN 上被提及。那里可能有相关详细信息：

https://www.phoboscn.top/t/topic/395/5

[github-actions]

Nightly build for this pull request:

• compiled-dll-1777d58b3b763ec806008ed1186bccd53238fa41.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]

I think this is more of an issue with Locomotor WH. The design of Locomotor WH is shit from the very start. It makes units replace their Locomotor and move on their own to the attacker to simulate a "pulling" effect, which causes problems once the unit refuses to move.
But I think no one is willing to deal with this shitty design. So just let this shit be.

[DeathFishAtEase]

Tested by: https://www.phoboscn.top/t/topic/395/8

[DeathFishAtEase]

The design of Locomotor WH is shit from the very start.

Neither the design nor the implementation; sometimes setting a destination cannot override the original destination of the target unit.

Even in the test of this early stage of repair, I encountered the above situation. In this fix, because inserting the check for IsAttackedByLocomotor into the original function was not easy, I once drastically modified some hooks. During that process, I encountered a situation where the IsAttackedByLocomotor check passed, allowing the unit to move, but as a result, the unit went to its own destination set by other factors instead of going to the attacker's side. Additionally, due to many problems, I finally gave up that thankless repair method and chose the current one that is simpler and theoretically more universal.

[Coronia]

pretty sure Speed=0 preventing aircraft lifting up is intended: 7333a45

[DeathFishAtEase]

pretty sure Speed=0 preventing aircraft lifting up is intended: 7333a45

This does not prohibit aircraft from taking off; the judgment only applies to VehicleTypes with Speed=0, and it may still prevent VehicleTypes with Locomotor=Fly from taking off.
For vehicles with Locomotor=Jumpjet, a usage scenario is mentioned in this topic(/395).
By the way: if we really want to impose restrictions on Locomotor=Jumpjet, it should determine based on JumpjetClimb/JumpjetAccel rather than Speed.

In addition, through testing on the latest commit of the develop branch, it has been confirmed that currently CreateUnit creating Jumpjet vehicles such as [ZEP] does not prohibit their vertical movement; for example, when BalloonHover=false is set, they will still fall to the ground.

[DeathFishAtEase]

Note

Since 7333a45 is later than the last DevBuild version (48) before Pre-Release v0.5, the change to the flag required to apply the stillness effect to Locomotor=Jumpjet vehicles is not recorded in the document as a migration item.

[Starkku]

Speed=0 is basically a legacy alias for a separate key like Immobile=true at this point. It should keep making jumpjets immobile even if it doesn't make semantic sense.

[DeathFishAtEase]

Speed=0 is basically a legacy alias for a separate key like Immobile=true at this point. It should keep making jumpjets immobile even if it doesn't make semantic sense.

What about using JumpjetAccel as a criterion? I see that the Jumpjet created by CreateUnit still moves in the vertical direction, so JumpjetClimb is not suitable for use here.

[Starkku]

What about using JumpjetAccel as a criterion? I see that the Jumpjet created by CreateUnit still moves in the vertical direction, so JumpjetClimb is not suitable for use here.

Rather not overcomplicate this. If it were up to me I'd replace Speed=0 with a separate key like I illustrated above but I'd rather not introduce breaking changes unless actually necessary. It actually used to be like that but someone (ill-knowingly) argued against it and for reusing Speed and I didn't realize any better either.

If one insists on making it different for JJ's then it obviously should be JumpjetSpeed for parity, but idek.

[DeathFishAtEase]

Since it's been some time, I've forgotten some of my thoughts at the time, only remember that due to some design factors, I needed to avoid JumpjetSpeed.
Overall, my initial goal was just to address the issue that a stationary vehicles could not be moved by external factors. I have temporarily decided to set Speed=0 for now, and if I remember later, I may open a separate PR to handle it.