If a "moving" item is not moving by at least 25cm per
second, then assume it's "stuck" and allow it to build
up "potential" for tunneling, up to a sane limit (to
prevent it from getting so large that it's likely to cover
mostly unloaded mapblocks, which would actually
reduce the probability of settling).
This should get rid of any remaining "deadlocked"
item entities that can happen in the normal course of
gameplay.
It's apparent that the barrier of needing to be able to maintain
a consistent art style myself without depending on external artists
is a significant barrier to being able to accept all but the most
isolated artwork changes. I really only NEED occasional help with
specific things, like maintaining the player character model and
animations, and in other cases it's probably better for people to
just make texturepacks for NodeCore and distribute them themselves.
Just hold the zoom button for a couple of seconds
(gives the player a chance to take screenshots with
the fixed zoom level) and then progressive zoom will
kick in automatically as long as zoom and no other
input control is held down.
This also prevents problems with the sneak/aux
causing unwanted movement while zooming.
If the below node is unloaded, kick the pos back
into the queue for reprocessing.
Do shuffled batches instead of just walking the
pend table in order, so that jobs stuck in the queue
due to unloads won't starve other positions for
checks.
In the special case of gravel that's at the bottom
of a mapchunk, we have no way to tell if it's held
up from below, so for safety, we don't want to
leave it potentially floating, but we also don't want
to carve out air voids underground just because
a gravel deposit sits at the bottom of a chunk, so
replace the bottom gravel with stone, so that the
column will be supported. Underground, a little
extra stone that just so happens to hold up all
gravel that sits at certain y levels every 80m will
probably not seem remarkable (I was unable to
find obvious examples of this effect while testing
for far longer than it took to notice the air voids).
Adding cobble/sandstone just arbitrarily holding
up gravelfalls looks awkward. Instead, just clear
them out, like they fell long ago when the stone
weakened into gravel but were scattered long ago.
Instead of wasting compute cycles running falling
node physics on freshly generated terrain where
the player would only see the aftermath anyway,
just shore them up with non-falling alternatives.
Nodes are checked for falling automatically upon
mapblocks being loaded, and also every now and
then in the background. In most cases this should
mean that nodes that should fall will fall as soon as
they are loaded, or pretty shortly therafter, and in
rare cases where something is missed, they should
"catch up" eventually.
Processing falling stuff is surprisingly expensive,
especially when loading an ocean floor where nearly
every node is a sand node, so a lot of complex
optimizations and limits were put in place to prevent
this from lagging the game. Pre-checks are done to
avoid calling MT's builtin falling check code, which
is surprisingly inefficient (even by MT standards) and
limits prevent it from either taking too much time
itself or spawning falling_node entities beyond a
safe limit.
Spontaneous node falling was intended to serve two
purposes originally:
- Prevent falling nodes from remaining nonsensically
suspended indefinitely from bad mapgen.
- Add a bit of tension to the game, back when it was
envisioned as more "hardcore" in more traditional
a sense.
The feature no longer fits with the tone and themes
of the game today. Sudden cave-ins caused by the
"sound/vibrations" of players disturbing an area are
largely indifferent to most players, confusing to
some, and very much hated by a few.
Snuff, ignite, and growtrees now use server priv
instead of debug, to be more consistent with other
server maintenance cheats like quell and stasis.
The "debug" priv may be granted to give players
read-only access to more info in the world, so use
the "server" priv for more read/write access.
Before, non-node items (tools and craftitems) were
exempted from opacity entirely and were always
transparent. Now, they use the same optic_opaque
and optic_transparent groups, are opaque by default,
and honor the sunlight_propagates heuristic (even
though this is rarely used for non-node items).
The following things were nodes that were defined as
sunlight_propagates = true but NOW will be opaque:
- shaftcraft items like sticks, staves, bars, rods, ladders,
frames, and torches
- flora such as rushes and flowers
- sedges, but only at max growth (make it now possible
to detect and automate sedge growth)
Instead of using variadics, hard-code array accesses for the
expected arity of door_operate_core, throwing away any
"future-proofing" that variadics were supposed to offer.
This is because in Lua 5.1, the length of arrays that contain
nil values anywhere in the sequence is apparently undefined, and
implementations are free to return the position of any value that
is followd by a nil, so length of {1, nil, 3} could be 1 or 3.
PUC lua seems to generally return 3, but LuaJIT takes more
liberties here (presumably exploiting UB for optimizations).
The problem arises when trying to unpack({1, nil, 3}) and LuaJIT
sees the length as 1 so return only <1>, instead of <1, nil, 3>.
This means that calling nodecore.door_operate(pos, ni, dir),
which was INTENDED for this API (it would look up node for you if
you didn't provide one) could result in the dir param being
lost due to packing the args into an array to defer them, and then
that array getting only partially unpacked.
Reference to WONTFIX bug where LuaJIT claims this is allowed UB:
https://github.com/LuaJIT/LuaJIT/issues/527
The solution for now is to stop relying on unpack (which is sort
of easy in its own way since I never really liked it). In the
specific case of nodecore.door_operate in particular, adding
more positional args (it already has 3) would be bad for other
reasons (should switch to a named passing style).
Some external rotation mods may change the way
node rotation works and put doors into a state where
they are one of the 12 "reversed" rotations instead of
the 12 "canonical" ones. Renormalize door facing
before processing rotations to ensure that these doors
are corrected automatically.
Deprecate the old APIs that used to close over the
metadata about valid node rotations. Now expose
this data in the node definition, and use a generic
non-closure function to handle the callback.
nodedef.spindata contains:
qty = number of allowed rotations total
cycle = table keyed on current param2 and valued with
next param2 for next rotation
equiv = table keyed by each possible param2 (24 keys)
and valued with canonical equivalent for that param2
...along with possibly other downstream bugs.
We had stripped the metadata off the wield item in the
pummel state tracking to make it so that changes to
wield item metadata (especially things that could be
changed by AISM while the player is using the thing)
would not cancel a pummel, but forgot that the wield
metadata that gets put into the pummel state is ALSO
fed to the recipe check. Use a separate key for this
stripped only-for-comparison version, and keep the
proper itemstack with full meta for recipe checks.
NodeCore will probably never use this itself, but it
can be used for mod content (i.e. Winter's waterlogged
containers) that will never allow infiltration of air
whether the sides are open or not.
While we don't need to include these in the .tr file, if the
translators verified that the translated string matches the
source string (e.g. lines with only a URL or other technical
information) it still counts toward translation completion %.
