Allow Laser drawing position update

[DeathFishAtEase]

• Now you can define whether the endpoints of a laser drawing are updated during its duration.
  • None: No update.
  • Firer: The start point follows the firer's FLH; if the firer dies, the update stops.
    • Since the FLH of DiskLaser actually determines the center of the ring, in this scenario, during the update process, the direction of the line connecting the beam's starting point to the center is fixed relative to the ground and the distance is constant - that is, the starting point will still remain on the ring.
  • Target: The end point follows the target; if the target object dies, the update stops.
  • All: Equivalent to specifying both Firer and Target.

move.mp4

Used together with Projectile interception logic

Note

In vanilla, an occupied building uses the weapons of its occupants in turn. Thus, if an infantry's occupy weapon uses Firer , the laser's starting point will update to the position specified by the most recently used MuzzleFlashX after each shot.

Note

For a sub-weapon created by ShrapnelWeapon or AirburstWeapon, its start point is the position where the parent weapon detonates, not the firer's FLH.

• If Firer is set, it will be treated as None.
• If All is set, it will be treated as Target.

In rulesmd.ini:

[SOMEWEAPON]             ; WeaponType with IsLaser=yes or DiskLaser=yes
LaserPositionUpdate=none ; Position Follow Enumeration (none|firer|target|all)

Warning

If the weapon sets this logic to a non-None value while also using other logics that change the drawing position, such as FlakScatter, then after initially drawing the laser according to those other logics, the drawing position will be forced to change due to the update rules.

[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/478/1

[github-actions]

Nightly build for this pull request:

• compiled-dll-20da4b73edb83ad3391ea29f6276be29a0820247.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.

[DeathFishAtEase]

Since a certain error introduced during local testing of Phobos Build#46 - Phobos DevBuild#47 may cause TargetCoordOffset of BuildingType to be not respected, and the functionality of this PR may mask that error, I will first focus on investigating that existing error and optimizing this PR, rather than immediately completing and merging it.

96c6550

838c2e7 (#1553)

Resolved in #2222.

[TaranDahl]

I thought those were supposed to be several GIFs

[DeathFishAtEase]

I think it's that after further refining the scope, I forgot to remove the image of Ares 3.0p1 without Phobos, so perhaps the three images arranged together earlier looked a bit confusing. :P
However, I have located it!