Instead of queueing inverted ABMs and then running
them out-of-band, run them inside the normal ABM
schedule time. This should:
- Prevent ABM mux lookup problems caused by nodes
changing after a delayed inverted ABM schedule and
the action actually running
- Allow the ABM scheduler to better account for the
time spent running inverted ABM actions, to ensure
that they properly count against the default 0.2s
ABM runtime budget and can't spike lag up higher.
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.
