Changes to the stack stored in a storebox do not trigger a node update,
which meant that affected optics to not get updated until the next ABM.
Use the newly introduced storebox_register_on_stack_change to trigger
a check on dependent optics just like node updates.
Storeboxes such as shelves do not let sunshine propagate because some of
the sides are opaque, but some sides are still open, and these should
still let light through.
During the optic scan phase, handle opaque nodes with visible inventory
by checking if the light travel direction also allows storebox access,
(from both the front and back face) and consider the node transparent in
such a case (unless, of course, the contained items are opaque).
Placing a sedge into a container via right-click would
randomly transform the sedge to one of the 5 different
random stages of growth, same as placing on the
ground would, causing non-sedge_1 sedge items to
exist which don't stack with normal sedge_1 anymore.
Instead, simplify the growth feature to apply the
change to the sedge in node form after it's been
placed, instead of manipulating items.
Move unconfirmed/unreproducible issues to a separate
"rumors" file, move issues back to main lists only once
we've found a way to confirm or otherwise understand
them (or really just go ahead and fix them immediately
if possible).
A certain arrangement of door-gears with a couple of
pieces of sand next to it can get in a situation that
causes an infinite loop, e.g. as if the sand nodes are
trying to switch places with one another and form a
circular dependency.
The simplest patch for it is just to limit recursion
for now. Randomness in the depth reduces the risk
that machines themselves can get stuck in some
pathological state.
Aux+sneak+drop is supposed to drop all stacks
that match, but it was dropping one item from the
selected stack first before dropping the rest. This
caused (1) dropping a stack of 1 might cause the
rest of the matching items not to drop, and (2)
dropping leaves or sticks or other stack-as-node
items would place a node.
Instead, suppress immediately dropping any
items at all when using aux+drop or
aux+sneak+drop and handle all drops in the
delayed stage.
- Regen with LBM too.
- Allow different delay time for "just loaded" case.
- Use DNT auto-start for more things, replacing
regen ABM/LBM where possible.
Also tried to improve door ablation reliabiity:
- Use DNT autostart for door ablation.
- Faster DNT check so we don't need the ABM
neighbor scan anymore.
- On early ablation trigger, set DNT for right after
cooldown ends instead of letting DNT loop die,
removing one scenario that could cause
sponge squeezer stalls.
Reconstructing a stack by transferring items from another
stack into an empty one, and then re-serializing, can cause
the fields to end up in a different order in serialization, which
causes a false positive detecting stack changes, which cause
another recheck, leading to a stack overflow.
Compare objects structurally, i.e. their key/value pairs,
rather than relying on stable serialization. The old method
only worked reliably in the case of objects having only one
meta field, which accidentally had worked out most of the
time, but doesn't work well with some mods, e.g. cats that
have both a name and furball metadata.
This seems to reduce steady-state bandwidth
usage when standing still significantly, at least
according to rudimentary tests.
Try to reuse the entity that is already physically
closest to the target position, so to maximize
the chance that nearby player(s) already have
the entity transferred and only need the new
pos data, in case MT is intelligent enough to send
only the needed changes.
During processing of the flammable ignition ABM,
nodes could ignite, causing the new ember nodes
created by this ignition to trigger fire propagation
instantly during the same tick by nodes still yet
to be processed for ABM checks during the same
scan. This often caused large areas of flammable
nodes, like wooden plank skyblocks, to be ignited
instantly in a specific direction from any source
ignition. This led to some "cheap shots" where
players were ruined by fire far more rapidly than
they should be.
Instead of processing flammability checks in
sync, delay them until the next tick, so that we
find all flammables to check before any new
igniters are created. This should tame fire
spreading back down to normal levels.
