Introduce CanEverReachTarget in the Attack component to check whether
a target is geometrically reachable at all, accounting for height
offsets and turreted units inside buildings.
For non-parabolic attacks (e.g. melee), a simple 3D distance check
from the closest approach point is used.
For parabolic attacks (e.g. ranged), the parabolic range formula
is used to determine if the height difference is surmountable
from the closest horizontal distance to the target.
Add GetClosestApproachDistanceToTurretPoint to TurretHolder
to estimate the minimum horizontal distance to a turret point,
using its local offset and the holder's obstruction size.
Passable buildings are not considered obstacles.
Fixes units on the ground trying to attack unreachable units on walls
or towers when the projectile's arc cannot reach the required height.
Avoid duplication by moving the function to Transform.js.
Add tests to Transform.js
Add tests to TurretHolder.js
Optimize slightly Trainer.js by removing some useless
Engine.QueryInterface calls.
Refs #6784 (symptoms in TriggerHelper.js are fixed underlying cause not)
`SkirmishReplacer` is called before the Modifier Manager so it does not
suffer the same fate.
Entities using `ChangeEntityTemplate` function are still affected.
Maps calling Engine.AddEntity directly are still affected.
Ideally this should be handled by hotloading components instead of
creating new entities each time. See =>
https://code.wildfiregames.com/D4991
Tested using:
908dd631d9
Differential Revision: https://code.wildfiregames.com/D4984
This was SVN commit r27636.
This basically does two things:
- Allow turrets on moving entities (fixes serialisation in cmpPos).
- Allow an entity to be present on another when the other is created.
That makes it basically a boiled down version of a prior patch, omitting
the part where orders could be passed on.
This does allow e.g. ranged units on chariots that fire while the
chariot moves.
Original diff by: @sanderd17
Redone by: @Stan
Differential revision: D1958
Comments by: @Alexandermb, @Angen, @bb, @Langbart, @Nescio, @Stan,
@wraitii
Refs. #2577 by implementing the entity on platform case.
This was SVN commit r25192.
While they often look alike, their behaviour is totally different.
This split has some implications:
- There are now separate auras for garrisoning and turrets.
- Entities can now have both turret points and garrison slots,
independent of eachother.
In general previous behaviour is maintained as much as possible.
Differential revision: D3150
Comments by: @Nescio, @wraitii
Tested by: @v32itas
This was SVN commit r25123.
Meaning GarrisonHolders won't listen for GlobalEntityRenamed messages
uselessly for the rest of the match after init.
Refs. #6081
Differential revision: D3627
This was SVN commit r25029.
Follow up on 8bfb449375. Allows saving turret positions in the map file,
instead of relying on the order in which the entities are added.
Differential Revision: D2614
Reviewed by: @wraitii
Comments by: @Angen, @bb, @vladislavbelov.
This was SVN commit r24161.
The logic concerning visible garrison points (i.e. turrets) is moved
from `GarrisonHolder` to a separate file.
This is logical because garrisoned != turreted, so this allows for
turrets that cannot be garrisoned (refs. D1958).
Also references #3488.
Differential Revision: D2367
Reviewed by: @wraitii
This was SVN commit r23856.
