While they may be only 'visual' in terms of influence/cell grid,
they all do update CenterPosition, which is essentially the
actual world position of the actor.
'Visual' would imply that it only affects the position where the
actor is drawn, which is inaccurate.
Furthermore, using the term 'Visual' here would make
naming future methods/properties related to visual interpolation
unnecessarily complicated, because that's where we might
need a real 'Visual(Only)Position'.
Inits that are logically singletons (e.g. actor
location or owner) should implement this interface
to avoid runtime inconsistencies.
Duplicate instances are rejected at init-time,
allowing simpler queries when they are used.
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
This allows callers to efficiently enumerate these returned collections without the allocation and overhead imposed by the IEnumerable interface. All implementations were already returning arrays, so this only required a signature change.
On large maps, it can take the delivery aircraft longer than the crate's
lifetime to reach the paradrop location, so the crate will be destroyed while it's still in the aircraft, leading to an attempt to get a trait from a destroyed object in the Paradrop trait.
This fixes the lifetime logic of crates so that the lifetime will only be increased when the crate is actually in the world. This will probably also better reflect the intention behind the Lifetime property, which I assume was meant to be the time the crate would be on the map available for pickup, rather than the lifetime of the actor itself.
