This speeds up performance of soaking API by
quite a lot, especially in the more or less
pathological case of soaking dirt to sand, which
involves clearing the metadata from thousands
of nodes each run. Knowing that the nodes
had already had their metadata cleared is
very helpful.
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).
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.
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.
See if this helps smooth out performance
issues in 5.3+. It was never confirmed to
increase the number of ABMs we were able
to successfully process anyway.
Detect ABMs that share the same "signature"
except for the central nodenames, and use a
single ABM to run them, looking up the core
bodies to run based on nodename on the Lua
side. This could reduce the total number of
ABMs we're using by almost half, and
mitigate some of the performance issues
that MT continues to have with ABMs.
By restricting the recipes we check based
on the name of the central object being
checked, we can do many fewer craft
checks per item and avoid expensive
checks.
When unlaundered ABMs run, give the
laundered ABM pump a rest for 1 tick, to
ensure we don't run 2 batches worth of
ABMs on any 1 tick, to smooth things out.
Instead of using 20% of CPU time to run
ABMs, defer 75% of them, so we are using
20% time to run 20% ABMs plus defer
a further 60%, giving us a total of roughly
80% CPU time for ABMs (not factoring in
overhead).
This should let us work around the engine's
hardcoded 20% ABM limit.
- New Delayed Node Trigger API that allows
the use of multiple externally-defined node
timer events, as long as on_timer of a node
is not explicitly overridden.
- Use the new DNT system to make door
ablation reliable.
