Before, ABM firing was delayed by up to a full
interval, but the fulfillment timer could wander
around relative to the trigger, which could lead
to unreliable door ablation.
Instead, just always run the ABM fulfilment
triggers on the next tick, so limted_abm is
ONLY doing the limiting for events that arrive
within the same tick, as most ABMs do.
Apparently we can't trust node meta to return
the same data to us that we just pushed in for
a few seconds, so check an in-memory cache
first and only use the meta for newly loaded
areas.
Bug was introduced in 16a7c9fe, caused by
the fact that sometimes nodes are dug by nil,
i.e. the way the chisel is dug up automatically
in the chiseling process.
Place as an empty stack node (soon to be
replaced by the server as a non-empty one
anyway) so laggy clients can right-click with
dirt earlier.
This should mitigate Kimapr's high-latency
mass tree farming woes...?
When digging a node that defines both a drop_in_place
and a drop (e.g. tarstone) silktouch wasn't canceling the
drop as well as the drop_in_place.
When we're using silktouch, assume that both drop and
drop_in_place are meant to be canceled, and move
the drop into a new drop_non_silktouch member, so
the builtin/engine doesn't process the drop.
Defer and coalesce visinv entity creation/removal
checks until the next tick, so we can process them more
efficiently in a batch.
The spawn area of the Community MP server was
lagging to something like 6x the dedicated step size,
due to the huge number of dropped items. This code,
on the same machine, seems to appear the same to the
player, but produces almost no measurable lag.
- Players no longer constantly glow in darkness.
- Players can now place light spots by scaling, faster
than actual climbing spots.
- Climbing spots appear if player continues placement
after light appears.
- Floor traversal mechanism is now obsolete.
This allows players to traverse dark caves reasonably
well, still, but only voluntarily, so darkness stealth
mechanics are possible again.
Apparently some users have had problems installing NodeCore because
they assumed it was a modpack and just copied the mods/* into
~/.minetest/mods and enabled them in an MTG game world. The result
apparently didn't immediately crash but wasn't really playable
either.
Detect NodeCore being combined with a mod named "default" and
throw an error immediately. This should catch like 90% of the
games out there. Some like LoTT or IKEA don't use a default, but
they're also not the ones that players would naively try to run
arbitrary mods on top of.
If the node we want to place dynamic light in is occupied (e.g.
player is inside a ladder node space) then allow placement on one
of the 6 face-touching spaces. This makes dynamic lights work
correctly on most ladders, and may fix other similar situations.
Instead of registering the TTL for a light and expecting
more time to be pushed in, use a fixed TTL of 0.25s and
register a callback to check if the light is still valid, i.e.
lights now pull time as necessary.
This should prevent light flickering that can happen
under heavy server lag, i.e. when the time step is
wider than the dynamic light TTL.
Lights that don't register a callback will be ephemeral,
and will disappear after 0.25 seconds, which can be
used to increase the chance that the server has had an
opportunity to move the light, as per torch destructor.
- 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.
The MT client crashes sometimes when trying to do a
lighting calc on upright_sprite entity visuals.
This may or may not be fixed in a future release, since it's
a heisenbug and a rare use-case, so for now try to
eliminate use of the rare and poorly supported upright_sprite
visual type by making empty inventory slots craftitem extrude
meshes.
As a limitation, for now, virtual_items such as injury or
lux burns will be invisible instead of showing the icon, as
we can't swap out the texture like we could for upright_sprite.
The MT client crashes sometimes when trying to do a
lighting calc on upright_sprite entity visuals.
This may or may not be fixed in a future release, since it's
a heisenbug and a rare use-case, so for now try to
eliminate use of the rare and poorly supported upright_sprite
visual type by making empty inventory slots craftitem extrude
meshes.
As a limitation, for now, virtual_items such as injury or
lux burns will be invisible instead of showing the icon, as
we can't swap out the texture like we could for upright_sprite.
