Under heavy lag conditions, physical entities may
land on the ground at any point during a time
step, but if they have a lot of horizontal velocity
then they may "slide" along the ground, and if we
only check for settling based on their pos at step
times, they may have already slid some distance
dependent on luck and the actual amount of
server lag. This means that under heavy lag
conditions, items may spread out inconsistently
from their landing positions and make a messy
pile.
Using the MT 5.3+ moveresult parameter of
entity steps, we can easily find out when the
initial ground contact occured, and use that as
the settling position, which should be more
consistent under lag conditions.
This has the effect of making entities more
consistently "sticky" so they always tend to
stick at the point of initial contact and rarely
slide or glance along the ground, unless they
hit an edge/corner.
Items being "bumped up" upon landing due to the new column
preserving falling mechanics will never be lifted to higher than
the local maximum posiiton from which they fell.
This should prevent e.g. planks tunneling up several nodes from
a log chopping machine if there isn't enough room for the planks
to escape and the chopping machine is enclosed from above. Items
can still tunnel using the normal "settling" mechanics, but will
not have the strong upward bias that the column settling mechanic
gave them.
When an ent settles, start an iterative process
of checking each ent near it for settling, bumping
ents upward as needed (during the process only)
and keeping them ordered by their starting height
so that things that start lower settle earlier (and
thus remain lower) even if ents have fallen and
bunched up together due to physics and large
timesteps.
Seems to work fully for falling_nodes (keeps
them in a column and settles them in order), and
partially for items (keeps them in a column but
does not always settle them in order).
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.
