- Climbing long ladders is often necessary (deep mining for key
materials like molten rock) and boring.
- Running-up-ladder prevention hasn't really been working right
anyway; it's trivial to bypass it by "wiggling" as you climb.
- Ladder running prevention was done as a "realism" thing, which
we are always prepared to sacrifice if it interferes with fun.
Instead of simply allowing the previous "exploit" allowing players
to run up ladders as long as they're "running" into them, actually
allow fast ladder-climbing (and up-swimming) as a first-class
feature.
We tried this first back in 5.0, and found that there were issues:
- Some collision detection stuff broke.
- It felt choppy.
- Didn't work consistently on Android.
- There was already auto-jump anyway.
Since then, with the addition of auto-run, auto-jump has not felt
sufficient, especially for climbing terrain or staircases. There
have also been a number of updates since the last time stepheight
was tried, including to collision detection and movement.
It's time to see how this feels in actual gameplay again.
Set stepheight to just a little above 1, so player can step up
a full node, plus a little margin of error for rounding etc.
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.
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.
