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