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.
NodeCore vanilla shouldn't be affected, since things that are
damaging are already not diggable, but for mods, this allows
some nodes to be damaging if punched, but diggable with the right
tool. Note that they will have to drop something other than
themselves because touch damage will still apply to carrying the
item in inventory (i.e. "hot potato" mechanic).
Don't reuse damage_per_second for damage on punch and radiant
damage. This allows these to be defined separately, i.e. no longer
assuming that all damage is from "heat" and can radiate. This
allows for things like thorny plants that hurt if you touch them
or stand in them but not if you stand near them.
Thanks to WintersKnight94 for reporting this.
If a player has sufficient upward velocity, then the gravity
reduction meant to slow downward acceleration instead slows upward
deceleration and the player flies ridiculously high. Doesn't
happen normally in vanilla, but can happen with mods.
Thanks to Lone_Wolf for reporting this.
NodeCore was already using sounds this way, i.e. assuming
they can't meaningfully be managed (may not be heard by
players just entering the area) so might as well get the
supposed performance benefit.
Added an override to allow sounds to be marked as NOT
ephemeral just in case it's needed.
