Right-clicking on the top of a shelf would place a legacy plantlike
eggcorn. This was due to the storebox right-click override
unconditionally calling `item_place_node` when placing an item against an
inaccessible side of a storebox.
The solution would be to call `item_place` instead, since that function
has the logic to handle `place_as_item` correctly. However, this cannot
be called from the storebox right-click override directly because
`item_place` calls the `pointed_thing` `on_rightclick`, which would
cause an infinite recursion.
Solve this by refactoring the placement logic into a new
`minetest.item_place_node_or_stack` which is called by `item_place`,
as well as by the storebox right-click override when placing items.
If an item stack is present in the node below a form,
the stack in the form will not fall into it even if it could add to it
(e.g. a 16-sand stack in the form will not fall into a 2-sand stack
below).
This is due to the item stack node being non-buildable-to and missing a
can_item_fall_in method, causing the stack_can_fall_in checks in
storebox_check_item_fall_out from failing when the shouldn't.
Fix by implementing the can_item_fall_in method for item stack nodes.
The implementation follows the storebox one, without any “geometric”
checks on accessible sides.
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.
