Extra range for chasing and pre-firing

[TaranDahl]

Extra range

• Now you can adjust weapon's range when the firer or target are under specific conditions.
• ExtraRange.TargetMoving grants the weapon extra range when the target is in a moving state.
  • ExtraRange.TargetMoving.CloseRangeOnly is used to restrict whether the global default value only applies to units with CloseRange=yes.
• ExtraRange.Prefiring grants the weapon extra range when the firer is in a pre-firing state, including:
  • Vehicles with tags such as FiringSyncFrame%d.
  • Aircraft that are firing.
  • Buildings with tags such as IsAnimDelayedFire.
  • Infantry with tags such as FireUp.
  • Any unit with DelayedFire.
  • ExtraRange.Prefiring.IncludeBurst is used to decide whether the execution of burst is considered as being in a pre-firing state.

In rulesmd.ini:

[General]
ExtraRange.TargetMoving=0.0                     ; float, range in cells
ExtraRange.TargetMoving.CloseRangeOnly=false    ; boolean
ExtraRange.Prefiring=0.0                        ; float, range in cells
ExtraRange.Prefiring.IncludeBurst=true          ; boolean

[SOMEWEAPON]                                    ; WeaponType
ExtraRange.TargetMoving=                        ; float, range in cells, the default values refer to the descriptions above
ExtraRange.Prefiring=                           ; float, range in cells, default to [General] -> ExtraRange.Prefiring
ExtraRange.Prefiring.IncludeBurst=              ; boolean, default to [General] -> ExtraRange.Prefiring.IncludeBurst

- In vanilla, melee units have difficulty attacking enemies that are moving away, even if they have a slightly higher speed than their targets. This is because the game's pathfinding algorithm searches for a firing position in units of cells, which creates an unacceptable error for melee units, causing the targets to move out of range before they can get close.
- Units with various forms of pre-firing behavior have similar problems. The target may move out of range before they fire.
- This feature can solve the above issues.

[github-actions]

Nightly build for this pull request:

• compiled-dll-5fb2919f9a4dcd677b21ee34340f6d3e81df2c1c.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]

To understand what shit this is dealing with quickly:
Vanilla behavior (left): The BRUTE is slightly quicker than the tank, but it won't be able to fire at the tank when the tank is moving.
With ChasingExtraRange=0.75 and PrefiringExtraRange=0.75 (right)

[Coronia]

not sure if this is the proper solution to the mentioned problem. ChasingExtraRange as of now will be applied whenever the target is moving, so it can affect more cases than a literal chase

this sounds more like a new feature than a solution anyway. Maybe it's better to describe it as a series of ExtraRange which applied under different scenarios. So it would be ExtraRange.TargetMoving and ExtraRange.PreFiring which is not only tied to this specific problem. This tag pattern also allows us to add more conditional range modifier in the future

[TaranDahl]

not sure if this is the proper solution to the mentioned problem. ChasingExtraRange as of now will be applied whenever the target is moving, so it can affect more cases than a literal chase

this sounds more like a new feature than a solution anyway. Maybe it's better to describe it as a series of ExtraRange which applied under different scenarios. So it would be ExtraRange.TargetMoving and ExtraRange.PreFiring which is not only tied to this specific problem. This tag pattern also allows us to add more conditional range modifier in the future

@Coronia changed.

[Coronia]

tweaked the implementation a bit and now it should be mostly LGTM, but I'm not sure whether global tags are needed now that it becomes a feature instead of a fix. Maybe it's better to only let individual weapons able to define this like those target filter did

[TaranDahl]

tweaked the implementation a bit and now it should be mostly LGTM, but I'm not sure whether global tags are needed now that it becomes a feature instead of a fix. Maybe it's better to only let individual weapons able to define this like those target filter did

I think it's better to keep the global tags, because for those who want to use this feature in batches (like me), setting each type one by one requires a lot of work. I believe the global values are meant to save this effort.
Also, I think many existing and widely applicable tags have the problem of lacking global values.