Reconstructing a stack by transferring items from another
stack into an empty one, and then re-serializing, can cause
the fields to end up in a different order in serialization, which
causes a false positive detecting stack changes, which cause
another recheck, leading to a stack overflow.
Compare objects structurally, i.e. their key/value pairs,
rather than relying on stable serialization. The old method
only worked reliably in the case of objects having only one
meta field, which accidentally had worked out most of the
time, but doesn't work well with some mods, e.g. cats that
have both a name and furball metadata.
Everything in NodeCore should already be using
nodecore.gametime instead of minetest.get_gametime().
This API allows an offset to be adjusted between these,
allowing for skipping forward in time.
The idea is to offer an optional "realtime clock" feature via
a mod or config option to allow mobile SP players to advance
time forward for idle mechanics when the game is not
loaded and running, via the realtime clock, to make idle
mechanics more accessible to players on limited battery.
Apparently players and luaentities use the same metatable,
so the polyfill needs to check if it's a player or not before
choosing which get_velocity to call.
When this was setup, it was named generically
in order to support future functionality that
used the same heating/tempering/annealing
mechanics. Ironically this has actually only
caused problems.
Standard game mechanics will not mimic one
another, especially something this complex.
Anything worth making a system for nodecore
that's as complex as lode-working deserves its
own distinct mechanics rather than recycling
lode-working. So vanilla NC will not reuse the
metal-working logic anyway.
Mods were able to reuse the existing logic, but
ironically the only one mod that would actually
have benefitted from it (i.e. uses very similar
heating/tempering/annealing) just copied and
pasted the code from NodeCore anyway, which
not only didn't take advantage of the existing
mechanic provided, but actually made the mod
break the game when installed, because the
mod would replace functionality in use by
vanilla with an older version, and the copying
will always keep that functionality locked in to
an older version, breaking whenever future
changes to the base mechanic are made.
Rename the base mechanic to (1) get out of
the way of the existing mod, and (2) make it
more clear that this is NOT generic functionality
that can be used to create new metals, but
only specifically for lode, and if somebody else
wants a clone of this logic, they would need to
rename it to make sense.
Detect a translation that once had strings but became
blank due to an uncaught failure to download the
file from weblate.
Also make trace output a bit terser but more specific.
When stack data was moved from node meta
inventory to fields, it was automatically privatized
and no longer sent to clients, which led to the
unintended consequence of breaking client
enable_local_map_saving. Maps saved this way are
missing all stored item stacks, which can be a very
significant part of the gameplay and render the
maps useless for many purposes.
The default behavior should be to leave this engine
feature intact, with an opt-in option for those who may
have come to rely on the alternative behavior.
- New near_unloaded API that supports custom
distance parameter, map bounds check, and
some optimizations.
- Add area automatic unload check support to ABM
API and add to applicable ABMs, replacing many
old manual checks.
Note that the explicit unload check is only strictly
necessary when something will happen due to
a node NOT being present in the area, e.g. something
igniting due to absent coolant, or soaking quantity
being reset due to missing sources. In simple cases
where the absence of a thing causes the ABM to do
nothing, then the standard check can work because
the default action is to do nothing anyway.
We were using action log level for a lot of
things because by default MT does not seem
to capture info logs to stderr. On "production"
servers though this makes too much noise and
makes it hard to find actual player actions.
Servers that want info logging will just have
to configure/compile it in.
Lenses enter a "glowing" state to propagate signal
immediately as before, but now they don't actually
produce light until powered steadily for 2 seconds.
This should mitigate the risk of "strobe" circuits that
cause excess lighting recalculations and irritate some
sensitive players.
This gets rid of the 5.4+ "deprecated get_player_velocity" warning
and modernizes the code to use get_velocity() everywhere, while
still remaining compatible with 5.3 for now (tested). The polyfill
had to be on joinplayer because the nc_player_pickup auto-one-time
method of using after() won't reliably patch the player before some
other globalstep tries to read player velocity.
When MT 5.5 is released and 5.3 support ends, the polyfill just
needs to be removed to clean it up.
Also tidied up and consistentized the logging for other hooks.
