Should save a trait look-up for each path search. Also ditch bogus null checks (this trait is a must-have anyway, so we *want* to crash if it's missing).
If Maximum == Minimum but 'crates' < Maximum, the formula would simply return min + 1 regardless of max being identical to min.
Only adding 1 more crate if Maximum is higher than Minimum fixes that.
This considerably reduces frequency of repathing attempts without too much of an impact of in-game repathing speed, since most of the time the blocking actor doesn't move out of the way that fast anyway.
Add GrantConditionOn*Layer traits
This allows to
- drop some booleans from Locomotor
- drop a good part of the subterranean- and jumpjet-specific code/hacks from Mobile
- grant more than 1 condition per layer type (via multiple traits)
- easily add more traits of this kind for other layers
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.
