Mostly this entails just calling the engine "the engine" rather
than committing fully to the new name. It's better to just specify
which engine this runs on in fewer places.
The Minetest engine has now been renamed to Luanti. The "core"
namespace is now preferred over the "minetest" namespace for
engine/builtin APIs.
As part of this process, add an "nc" alias (now preferred) for
the nodecore API namespace as well, to save us a little code
verbosity.
Instead of having to register a special box sizing ratio, detect
it automatically from selection box information on the node
registration.
This also analyzes selection boxes of rotatable things and raises
warning messages on any that don't meet our simplicity/symmetry
expectations. These warnings represent real problems that should
be fixed as they could cause node selection boxes to move around
as a node is rotated, causing usability issues.
Currently all vanilla rotatable nodes follow a standard of having
a selection box that's a single symmetrical cube centered on the
node position center. This is already necessary to ensure that
rotating a node doesn't cause the selection box to move out from
under the cursor and cause repeated right-clicks to hit something
else beyond.
Taking advantage of this assumption makes it simple to just add a
single scale factor to:
- Make rotation hit zone regions consistently sized.
- Accurately place the HUD dots indicating the regions.
A more elegant hack may be necessary for nodes that are don't
meet the symmetry requirements, but it may actually just make more
sense to throw warnings if any are registered.
It "floats" on water or pumwater. Any liquid that has "liquid
movement physics" for players also supports pumice from falling.
This prevents a pumspill over an ocean from filling the ocean
below it with pumice.
This also slightly optmizes the direct-support-below check path
for pumice, as it's now an index lookup instead of looking up the
node definition and running on the fly heuristics.
Since sponges can now grow new lobes "remotely" it's fine (and a
fair bit simpler) to keep the remaining accumulated growth
potential inside the same sponge.
- Avoid processing the same sponge more than once on a single pass.
This avoids O(n^2) complexity.
- When any sponge has growth ready to push out, when we do the scan
to validate growth, also locate places where it could put the new
sponge "through" the colony. This compensates for the fact that
the one sponge "chosen" may be buried.
- Impose a strict limit that sponge colonies must fit in a 6x6x6,
to prevent a sponge in the "middle" of a long chain from seeing
only 3 on each side and thinking it can still grow, leading to
sponge "columns" up to 9 tall.
Tested using the "sponge fields" near spawn town on NCC.
- Before: ~70ms (35% of ABM budget)
- After: ~16ms (8% of ABM budget)
This is a small optimization that may reduce the tendency to
mark blocks as dirty, especially due to soaking ABMs that may
clear meta fields more widely.
It was previously named for the issue it was meant to work around,
but since that issue was closed, we are no longer waiting and
watching to remove this.
- Make it take 5 consecutive placements.
- Reset count back to 1 if there isn't already a scaling node
there, so players moving away from the area and coming back
again are less likely to accidentally trigger it.
This isn't as strict as I'd really like, but without tapping into
the scaling node placement checks (which I'm not quite ready to
try yet) it's hard to do better for now.
These may get left on the map from an upgrade, e.g. if a player
disconnected and unloaded the area before displacement could
reverse itself, leaving the node, and then the server was shut
down and updated.
One of the most confusing features for new players has been the
fact that they seem to be able to dig anything, but many things
take a long time, and when they finish digging it, they get the
weird "displaced node" that they can't interact with. It has never
really compensated for this problem by being a compelling way to
get "unstuck" when trapped.
Instead, experiment with a new way to get "untrapped" when trapped
within a solid barrier. By repeatedly doing the "scaling
placement" recipe on the same spot several times, instead of merely
being able to climb it, players can "phase through" solid matter
and quantum-tunnel themselves through/into a wall. If there is
space for them on the other side, they will be placed there. If
not, then they will be shoved into the wall, and can rely on the
"push out of solid" mechanism to eventually wander them over to
somewhere else, where they might have a better chance at getting
out.
This now makes being trapped in nearly arbitrarily deep caves
actually theoretically resolvable, because players should have at
their disposal some combination of navigation inside caves by feel
at their disposal, that lets the make clear progress toward going
"up", and can always try to tunnel into a ceiling for hopes of
conversion to a less deeply buried cave. This gives players a bit
more agency as well.
Some concern has been expressed about the use of this for bad
actors, but those bad actors have already had more effective ways
to circumvent barriers as it is, which don't suffer from some of
the randomness and unreliability of this method, so the downside
to this is expected to be limited.
When players are pushed out of solids, rather than just biasing
toward 0,0,0, if a static_spawnpoint is set, bias them toward
that position, assuming it's a "known good" location.
This reverts commit b77fb35338574ba99e0baa209630f48df76356ab.
Stack visuals are not updating, and the problem this fixes wasn't
necessarily big enough to justify dealing with this.
We weren't resetting the cooking progress correctly for cooking
item stacks (it was using the wrong meta key).
As pointed out by Lars, clearing a metadata key that's marked as
private seems like it triggers a block resend, even if the client
wouldn't see any difference in the mapblock. This means that
fixing these sorts of issues reduces server-to-client network
traffic, which is (anecdotally) observed with this change on a
copy of the NCC map near spawn.
Instead of a thundering herd of DNT calls 1 second after the
initial "regen" ABM has scheduled, them, spread these out over
time a bit to try to reduce lag spikes from them. The effect is
small but every little bit may help.
In practice this also stretches these calls from 1 to 1.5 seconds
between on average, reducing cooking check intensity by about
a third.
This is for an ephemeral effect, so it's not likely to be relevant
across server restarts anyway, and constantly checking for it in
node metadata is surprisingly costly, especially with it happening
thousands of times per globalstep on mature worlds.
Instead of always pushing rate * time -> total, only commit this
when there has been a change of rate or override of total. This
means that rather than updating metadata every time a soaking ABM
runs on a node, it will only get updated when "steady" soaking has
been interrupted, greatly reducing the volume of metadata writes
and dirty mapblocks.
This should work fine because the math was already designed to
work reasonably well when updates are "skipped" due to the map
not being loaded/active there. The only issue is that there is
a slight "double jeopardy" to soaking completion when the ABM is
running repeatedly because the random parameter is re-rolled each
check, so there's a better chance of getting at least one high roll
that completes the soak if you're making repeated rolls. This is
expected to be a small effect with current recipes.
This didn't seem to actually ever cause sprouts to repack into
dirt, but it did create some extra node meta value updates due to
contention between soaking ABMs.
This is useful to make sure that the HUD is synced with gameplay,
e.g. for doors where right-clicking with a "hinge pin" will try to
install the pin, and thus cannot rotate.
These are terribly inefficient, especially when there are a ton
of entities, as is the case when there are a lot of visenv ents.
For nodefall damage, filtering by whether the entity is a player
first is much more efficient than by position, since the rejection
ratio on larger servers is higher.
For checking if doors or totes are obstructed by falling or item
entities, this isn't even strictly necessary and maybe we should
just skip it and allow them to get "tunneled" in and settle
naturally. At higher step sizes, it's questionable whether these
would even be handled accurately in the first place.
Each region has a specific function. If that function is not
available, then that region is "dead" rather than being "taken
over" by another adjacent function. This makes sure that holding
the cursor in place and right-clicking repeatedly never suddenly
changes the operation, preventing unfair surprises.
In theory, in fact, not only does it never change from one
function to another, but it should never spontaneously become
a "dead" region; pointing at a dead region stays dead, and at
a live one retains the same meaning no matter how often you
rotate it (assuming other players aren't interfering).
Separate the "which facedirs are valid for a node" aspect from the
"which ways can a node be rotated" aspect.
- Remove the bulky "rotation data" object from node definitions
and instead just define an optional nc_param2_equivalent func.
- All disallowed param2 values are now automatically fixed at the
time a node is placed, so downstream mods don't need to do any
special filtering (though they need to be prepared for the
actual placed param2 to mismatch what they set).
- There's now a nodecore.param2_canonical(node[, param2]) command
that returns the correct node table with the correct allowed
equivalent param2 for mods.
I've apparently needed to Knuth-shuffle a table pretty often, and
have reimplemented it multiple times. We should instead assume
that the "standard" table.shuffle extension that MT adds should be
reasonably "optimal" and just use that everywhere. If it turns
out not to be optimal then it's still valuable to consolidate the
implementations.
All falling nodes displaced item stacks upon landing, including
loose leaves. This has always felt a little bothersome, and
poses extra risks on skyblocks.
Now instead, falling nodes that are "insubstantial" enough not to
be walkable (currently only loose leaves) will not displace item
stacks, and will try to displace themselves instead.
- We have already taken care to call savedb() only in places where
it's actually necessary, so we shouldn't delay it any further.
In particular, delaying it makes it useless to call on shutdown.
- We can apply at least a little intelligence and not set keys that
are already set correctly, taking advantage of the fact that keys
tend to be iterated in a stable order at least when the table has
not changed, making it easy to compare a table modified in-place
against a serialized old copy. This is about the best we can do
in terms of reducing modstore key writes.
- Remove a bunch of settings that change things that are meant to
be fixed standard values and not really meant to be tuned. These
were originally added to make it easier for modded games to
adjust, like skyblocks, but:
- It's better to use modding rather than user-visible settings
to adjust these.
- We ended up preferring to use entire new game mechanics to
adjust things (e.g. adding tree tickling) instead of just
changing settings (e.g. tree growth speed) because it was
just a lot more interesting gameplay-wise.
- Clean up setitngs names.
- Clarify meanings a bit.
- Use "system - setting" naming convention to make related
settings lexically group together.
Instead of spawning these when players first log in and have the
entities update their state on_step, just run a single globalstep
that walks across all players and inventories, and then across all
entities, in a couple of passes, and reconciles everything.
This should also deal with entities that are lost for random or
arbitrary reasons, which seems to be the remaining known cause of
wield items spontaneously disappearing.
The code is also simpler (a single loop with a few linear passes)
and probably more efficient.
