Before this, we unconditionally used the largest OuterRadius of all actors inside a mod for overscanning of blockable projectiles.
However, in many mods the only blockable actors are 1-cell walls, and even if there are gates like in TS, they usually aren't the largest actors in terms of hit-shape.
So this measure should save a bit of performance by reducing the overscan radius of blockable projectiles, especially in mods where walls are the only blocking actors.
Actors involved in the trigger are determined as actors move around near the trigger - and can be expensive in some maps. This allows us to avoid allocating new sets and the CPU hit required to set it up each time.
Re-evaluate before every spawn attempt instead.
Also accounts for ActorSpawner being conditional now.
While a bit more costly in terms of performance, this allows to create spawns mid-game.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.
The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.
Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.
CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.
Fixes#14151.
The RadarWidget can supply a reusable buffer to each trait to avoid individual traits having to return new enumerables. Additionally, this allows the two traits to avoid LINQ and further allocations as they can manually enumerate and populate the buffer themselves.
The number of distinct domains on a map is often dozens, or at most hundreds. We can use a ushort to represent this easily, and reduce the size of the backing storage required to track domain indicies over the whole map.
This avoids the allocations caused by LINQ when using traits.FirstOrDefault(Exts.IsTraitEnabled). This is important in FrozenActorLayer.RefreshState which is called very often. We apply the new helper method to all areas using the old pattern. An overload that takes an array allows arrays to be enumerated without causing allocations.
* Maintains lists of claims, and only restricts
reservations for friendly units.
* Removes OnNotifyResourceClaimLost; it's not
clear whether that is still useful, and it
prevents future necessary cleanups.
* Moves other code without changing behaviour.
This fixed stale claims from dead units and enemy
claims from preventing otherwise valid harvest
activities.
