It was checking the craft before actually placing
the node, causing the crude glass recipe to
complete when molten glass flowed into a mold
with water below, then it got replaced by the
source node, then it re-quenched to chromatic on
the next ABM pass. Now it actually quenches
directly to chroma immediately like it should.
As soon as an item is placed run a cooking recipe
check, so auto-furnaces can run at maximum
designed speed instead of having to wait for ABMs,
which may lag. This should make MP performance
also a lot closer to SP performance...
The idea is to unify cement and glass flowing, plus
add additional features: if there is no available
space, try to find the nearest dropoff to wander
toward even if flows can't actually reach it (assume
that the terrain subtly slopes that way).
Old behavior used to round exactly-off-by-half
values up toward +inf, but since
https://github.com/minetest/minetest/pull/10803
they are rounded toward +/-inf, which means that
if a player's y coord was exactly -1.5, it used to
round up to -1.0 but now rounds down to -2.0.
This affects using vector.round to get the pos of
the node the player's feet are standing INSIDE,
because if the player's y coord is exactly -0.5, as
would happen while they're standing perfectly at
rest on top of a node, it will instead give us the
node they're standing ON.
This causes spurious player "pushout" events,
because the game thinks players are standing
inside the node they're actually standing on top
of.
To work around this, just add a small positive
fudge factor to the player's y coord to bias it
toward +inf.
This was apparently causing sand not to cook if it
had another sand node on top of it, because the
inverted cooking ABM would detect the top sand
node only and not process the cook check for the
lower one.
- For inventory and wield images, this is already
possible via override.txt since 5.3.
- For special tiles, this will be possible in 5.4.
- This complicates things, and introduces warning
messages into mods built without awareness of
this feaure.
- As far as I know, no texture packs have actually
ever used this feature.
Node inventories are sent to clients, while metadata
fields are automatically set private by the server
and not sent to clients. Not using node meta
inventories may help reduce the amount of data
sent to clients, especially in storage-heavy areas
where we were duplicating the work of sending the
inventory data not used on the client, as well as the
visible item entities.
Automatically convert old-format data to new upon
reading.
Also, needed to provide some APIs for sane access
to data in serialized format, and another way to
signal that a node can accept a stack other than
the size of inventory[solo]
Now nodes other than sponges (i.e. downstream
mods) can create artificial temporary water sources
similar to sponge squeezing.
The API allows specifying a source node and position,
so the water will dissipate if the source node is
removed. A min/max TTL can also be specified, so
like the sponge, it can require external triggering to
maintain the water flow as well as the presence of
the node.
The original theory was that preallocating the array forced lua
to use the "array part" of a table instead of the "hash part",
which should be faster since lookups are a simple linear offset
calculation and not a hash with collision check.
It turns out, however, that in empirical testing, whether the
array-preallocated or the naive-allocated version is faster depends
on circumstances, such as how sparse the array is, how uniform
access is, or how much other load the system is under. This seems
to suggest that arrays are more computationally-efficient but less
cache-efficient, so cache evictions caused by other concurrent
processes may slow this method down significantly.
Worst-case performance will be the most noticeable here, since a
system that's heavily loaded would have the most need for speed
in the first place, so it's probably better generally to use the
naive allocation.
In all, the naive allocation method also seemed to be the least
sensitive to external factors. In addition to the array method,
attempts to pre-compile the dynamic checks into a binary tree of
if/then statements (which could be JITted and optimized) failed
as well.
- Apply logic as first-class support so we can still
have custom after_dig_node hooks.
- Shared flag nodecore.silktouch_digging that can
be used in after_dig_node callbacks to determine
if we're in the middle of a silk-touch dig.
- Add coal particles to tarstone digging if the coal
is destroyed/dispersed during the dig operation.
Once coal is mixed into the stone, it's "locked"
away. Breaking the hardened stone releases the
coal as a fine powder that's not recoverable.
I'd rather violate the 1st law of thermodynamics and
not preserve the coal here than violate the 2nd law
and have it neatly "unmix" itself back into a lump.
It doesn't catch 100% of everything, but presumably
it catches at least some things, and has little
marginal cost on top of the ABM alone.
Players have been remarking about the fact that
dungeons sometimes initialize right before their
eyes. LBMs SHOULD be able to fire outside of the
ABM active range, giving us a chance to catch these
a little earlier before the player is close enough to
notice...?
This was added to allow a player to get out of a
rare softlock (trapped inside a cobble room without
any tools). Since then we have not seen much use
of it for this intended purpose.
However, it has caused MUCH confusion among new
players, wondering why it takes so long to mine
dirt or tree trunks, instead of trying to figure out how
to make the proper tool.
Emergency digging is causing more problems than
it's solving and thus it makes more sense to remove
it than to keep it. If we need some mechanic to fill
its niche (i.e. a way out of softlock) then we will need
to consider something that's harder to discover
accidentally to avoid confusion.
The old system effectively cached cross-block
boundary information forever and never expired
them, even if the node creating them was
removed (that would have been easy to fix) or
an obstacle placed in the path (that would have
been difficult to fix with the old method).
Instead just do the simplest thing and split this
into a separate loop, and run a 2-second DNT with
a separate forward-trace from all active optic
nodes.
Doing a second forward trace for each node output
may not be as efficient but ultimately we create more
problems than we solve when we try to be too clever.
...similar to how loose items are.
- They're emphemeral/air-like anyway
- Prevent exploiting protection areas to make traps to
capture players or their items.
Before we were generating one spark spawner for
each ABM run, which could run hundreds of nodes for
a large blaze, and bunched them together. Instead,
push into a limited fair queue, and also spread the
actual spark spawning out across time to spread the
network traffic from fire.
To repro: place a sand node at least 2 nodes high above
glowing lode prills and let the sand fall onto the prills and
try to displace them.
Introduced in 01252653-5da0918.
For some reason it seems like a non-player object is being
passed as the digger (I thought it would be nil for non-
players?) and this object apparently imitates a player but
is missing some critical thing such as metadata.
To work around the problem, just add guards to the
phealth functions, since only players are intended to have
"health" anyway.
Wherever an optic beam strikes a mapblock boundary,
it now creates a particle effect visible to players close
enough. This can be used to plan circuits so they work
entirely within a single mapblock and thus are never
internally interrupted by unloading.
This is useful when we want to perform an
action on a commonly-occuring node (like
sand or item stacks) with a requirement of
a neighbor of a less common node type (like
igniters). Checking for B with A nearby can
be a lot faster than A with B nearby if B is
less common, so fewer neighbor checks
actually need to happen.
This was already done "manually" for the
flammable/igniter interaction, but now this is
a general API for all ABMs, that allows the
inversion to be done nearly transparently
with just a flag in the definition, and so the
ABM rules can be written more simply, with
the inversion handled elsewhere.
TODO: Rewrite current manual-inversions,
including the ones for flammable/igniter and
lava/stone hardening/softening.
This prevents a problem where players
can drop items into other players'
protected areas but cannot dig them.
Other solutions to prevent players from
placing items into protected areas in the
first place may be possible, and may still
be explored, but are not foolproof and so
this acts as a fallback at least.
A low-level player teleportation must be explicitly
declared nodecorian via a keepinv property on
the position, or the player must be exempted via
the keepinv priv, to be allowed to teleport without
leaving the inventory behind.
This means that naive mods like /home commands
will now work correctly and teleport only the
player, and not items.
