- 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.
