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.
- Merge the "legacy, could be anyting" sets
into every other set so we can do only 2
set lookups instead of 3.
- Make sure we don't do any duplicate
recipe checks.
N.B. the craft priority order MAY be different
now, since primary node recipes are
checked before visinv stacks.
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.
Register a "rootmatch" property for all
recipes that represents a broader, quicker
test for recipe eligibility. False positives are
allowed but false negatives are not.
Since most recipes are eligible, we can
use this to build an index for fast lookups
of subsets of recipes to run and skip most
of the other ones.
- Crash due to pos being non-nil but velocity being nil?!
- Excessive item merging, i.e. on splitting planks, cancelling
out outward item ejection. Items now only merge at low
absolute speed (detecting groups with low relative speed is
too difficult to do efficiently for now).
- O(n) efficiency walk of item entities
- Honor stack family merging, e.g. differing lux levels combine
Since the new walk should be much more efficient, the need to
handle "extremal" cases specially, e.g. creation of a multi-stack
ent, is probably unnecessary. Remove it from the task list,
barring any future evidence that it's still relevant.
Face-touching water can be converted to pumice instead of the
flowing lava (e.g. lava intrudes into that space and quenches
instead) creating even more of a mess.
If the server can't handle optics, it would lead to a
runaway effect and bring the system down. Instead
only process up to half a second worth of optics on
each tick, so that this effect is capped and the server
will at least be able to chug along.
Using pngquant this time, instead of GIMP. It seems pngquant at
least is smart enough to preserve the exact RGB value of the
single most common color used in all the images.
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.
