Stone is hardened by creating an elecric field via the Peltier
effect that causes internal crystals to align. Or something like
that.
Stone hardens over time when touching both lava and water.
All stratafiable stone types (lode sign, lode ore, lux ore) are
affected.
- 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.
