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.
This prevents the "running up a ladder"
exploit, and adds a bit of realism.
This MAY cause problems for players who
have sufficiently crappy network, so
hopefully the liberal stuck time of 2 full
seconds is enough. Players with that much
latency probably can't pummel, so probably
can't play anyway.
- Nerf effect by 50% to be less disruptive
- Effect can be avoided by not being in a
swimming position (matching model anim)
- Refactor swimming check into API
- Special checking and handling for linkdead
players, for whom client knockback
wouldn't work anyway.
This is done rather hackishly, but Minetest doesn't
seem to offer a sane way to register fluid buoyancy, or
even a reasonable hack to use negative gravity for this.
Instead, just push player upward with velocity impulses
every so often.
This is helpful gameplay-wise to make chatting while
swimming easier for players not using auto-forward, or
to prevent players from drowning and losing their stuff
while swimming long-distance and dropping network
connection and their in-game character waiting in the
water for the timeout. Instead, players will return to the
surface and remain where they can breathe until the
player can take control again.
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.
When 3rd-party mods try to register extensions, don't
crash on trying to register in wrong namespace.
Keep registrations to original mod namespace for now,
as I'm not certain whether I actually made assumptions
about mod name in some logic.
Lots of issues with players being unable to figure out traversal
of dark caves. Total darkness is probably too much of an ostacle
for players who haven't already learned how to avoid those kind
of circumstances.
All possible light level nodes are pre-registered at startup time
so that light levels can be determined fully dynamically at run
time, without needing to explicitly declare what light levels will
actually be needed.
Hopefully this will make using dynamic lights a little easier
and lead to some interesting content.
