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.
This is as FrozenUnderFog.TickRender queues an update to the screen map. If this is not processed in the same tick, this results in screen bounds for the frozen actor being 1 tick behind. By making ScreenMap TickRender, it ensures changes from both Tick and TickRender traits are processed, rather than just Tick traits.
This reverts commit 2eb090f153.
This fixes flicker for the actor->frozen transition, but then introduces the same flicker for the frozen->actor transition instead.
Since most traits have few syncable members, this allows us to avoid allocating an array whose lifetime is only a few ticks long. For traits with more members, we fall back to allocating the array.
We can use MergedStream to create a single combined stream with all the input and pass this to the hash function. This saves copying all the data into a MemoryStream to achieve the same goal, which requires more memory and allocations.
Callers can provide 3D points easily, and this avoids the need to allocate and slow down enumeration via the points.Select(p => new float3(p, 0)) wrapper.
Compiling these expressions is sadly expensive, and we needed new ones for every trait on every actor each time one was generated. The expressions thankfully can be shared as they are pure functions, which removes this overhead.
