When a thrown item settles into a node space and
becomes a visinv node, reuse the existing entity instead
of deleting the old one and creating a new one, if
possible.
The realism theory is that item stacks are "looser"
and more easily pushed out of the way. The
gameplay theory is that it's getting annoying
having machines like log or charcoal choppers
getting blocked by items under the falling nodes.
This is also hopefully part of falling-node stack
order reform, to fix that nodes sometimes fall
through each other.
Somehow an ent can get into a state where
it needs to set velocity but doesn't know what
velocity to set; velocities are transient
phenomena anyway, so just ignore this.
- Crash due to pos being non-nil but velocity being nil?!
- Excessive item merging, i.e. on splitting planks, cancelling
out outward item ejection. Items now only merge at low
absolute speed (detecting groups with low relative speed is
too difficult to do efficiently for now).
- O(n) efficiency walk of item entities
- Honor stack family merging, e.g. differing lux levels combine
Since the new walk should be much more efficient, the need to
handle "extremal" cases specially, e.g. creation of a multi-stack
ent, is probably unnecessary. Remove it from the task list,
barring any future evidence that it's still relevant.
- Move comparison check into object metatable so
it applies to all naive set_properties() calls. This
should help catching it in downstream mods.
- Remove sprite property filtering. It seems the issue
was actually caused by a 2D/3D vector
disagreement between caller and property def,
which the hack wouldn't have fixed for sprite-type
visuals anyway; it only actually helped in the current
code because the only entities trying to set them to
3D vectors in the first place were non-sprite.
MT apparently internally ignores sprite properties on
entities that are not using a sprite visual, and returns
dummy values, rather than preserving what was sent
in, on get_properties().
Guard against set_property() noise on future/mod
calls explicitly rather than relying on the caller not
sending these props in when not applicable.
Some time in the 5.3 dev stream (docs updated at
217f3a42), object refs started being invalidated
immediately on calling obj:remove(), such that
obj:get_pos() starts to return nil instead of the object's
last known position.
This can cause some crashes in NodeCore, where we
assume that our object is still valid (or usable as if it
were still valid) even though we're looping through
handlers and any one of them may have remove()d the
object before other handlers get a chance to fire.
Instead, just watch for unexpected nil returns from
functions we expect would never return nil (e.g.
get_pos or get_properties) and return if we hit one.
We can assume all other calls will be non-nil after that
one, as long as we stay in the same function flow.
This should more reliably minimize network traffic
incurred by excess property setting.
We could probably standardize a few more things,
like set attach, anim, yaw, pos...
Trying to make it so that the map lower bound
(via mapgen_limit) is solid to all built-in objects.
Before, entities would fall into this space, remain
until unloaded, and then be destroyed.
Falling nodes appear to work correctly.
Item ents still don't settle.
Instead of checking only in the center below an entity,
check a random x/z offset below its bounding box, so
an ent that's stuck on an edge will eventually detect
the blocking node below that edge and settle.
This created a ton of dependency inversions, which
necessitated moving a number of API functions up into
higher layers, and restructuring dependency lists for
a number of mods.
BOLO: non-deterministic load errors due to missed
dependencies.