It was always weird that the player character could
sense hinged panels even when the faces shown were
completely undifferentiated from their non-panel
counterparts. Add a fairly subtle visual indicator that
makes it obvious why the player can spot them.
Players can still hide doors in plain sight, they may
just need to take more advantage of shadows and
other geometry tricks to ensure they don't stand out
against a field of similar nodes, or use psychological
tricks to distract other players from spotting the
patterns.
- Fix door place-craft discovery not triggering due
to wrong label name
- Fix many door witnesses not working because the door
itself obstructs view of the action; "spread" the witness
event to multiple positions and give the player credit
if they can observe any part of the interacting nodes.
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.
- 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.
Look for optic_lens_emit group instead of explicit
lens_on node, to support multiple lens beam emitting
nodes (e.g. glued/unglued) for firestarting, door
ablation, etc.
When bypassing custom on_place logic and
skipping directly to "place as node" logic, also
allow nodes to customize their "place as node"
logic with another hook, which the tote can use
to ensure it's rebuilt when door-placed.
When this was setup, it was named generically
in order to support future functionality that
used the same heating/tempering/annealing
mechanics. Ironically this has actually only
caused problems.
Standard game mechanics will not mimic one
another, especially something this complex.
Anything worth making a system for nodecore
that's as complex as lode-working deserves its
own distinct mechanics rather than recycling
lode-working. So vanilla NC will not reuse the
metal-working logic anyway.
Mods were able to reuse the existing logic, but
ironically the only one mod that would actually
have benefitted from it (i.e. uses very similar
heating/tempering/annealing) just copied and
pasted the code from NodeCore anyway, which
not only didn't take advantage of the existing
mechanic provided, but actually made the mod
break the game when installed, because the
mod would replace functionality in use by
vanilla with an older version, and the copying
will always keep that functionality locked in to
an older version, breaking whenever future
changes to the base mechanic are made.
Rename the base mechanic to (1) get out of
the way of the existing mod, and (2) make it
more clear that this is NOT generic functionality
that can be used to create new metals, but
only specifically for lode, and if somebody else
wants a clone of this logic, they would need to
rename it to make sense.
- Normal non-selective raking mode works when
pushing a rake with a door.
- The rake does not pick itself up.
- Collected things are dumped at the location of
the direct raking target.
This doesn't seem super useful right now, but
a rake digging a full stack of some item will cause
all additional stacks of items in its range to settle
near the full stack, which could end up over a chute
allowing the item to fall down, and thus could be
used to collect items that scatter over a wider area.
Before releasing this we might consider making
rake digging selective by default, so these can be
used to sort and filter items.
May also consider making it possible to dig with a
rake in other circumstances, e.g. pushing a rake
against an open side of a storebox that has no room
for the rake will cause the rake to dig that stack and
all nearby matches?
May also consider cleaning up the raking API entirely
to make it easier to directly invoke a rake via
machine digging ... or tidy up the machine digging
API so it's no so hacky.
Make sparks bias "downward" for igniting nearby
materials, making starting a fire on top of thatch
more useful, and making thatch a more useful
tinder material.
Witness checks include data about the node in
place at the time that the witness even occurred,
so players are not awarded credit if the node they
see there was changed again afterwards. A lot of
old witness code inserted the witness right
before the node was changed, since the node
change was done as a tail call, but this does not
work with delayed witnessing because the
delayed witness data would be tied to the old
node, not the replacement one.
Moving witness to after node setting should fix
a number of broken hints that should have been
delayed-witnessable, e.g. brick bonding.
Check for a dig recipe first before attempting to
catapult item through the node. This should make all
non-solid nodes diggable including loose leaves,
sedges, rushes, flowers, etc.
Some users may use filtering but not have the "clean transparent"
filter enabled in the Minetest engine config. Bake this filter
into all images to (1) avoid the consequences of this (i.e. black
halos), and (2) possibly speed up startup time (the filter will
converge immediately).
Apparently metarefs are cached somehow such that
values written to them are not returned from subsequent
reads. Must be an engine bug, but it's probably not
worth trying to fix it at this point. Some startup jank
is apparently inevitable anyway, and a 2 second cooldown
time is not easily exploitable by restarting the world.
Items placed on top of a spinning horizontal door are
supposed to be flung outward preferentially and only
stay near the hub if held back by a wall. Rewriting the
door conveyance logic apparently switched this.
Try to make sure doors don't have to wait arbitrarily long
for a patrol ABM to fire if their DNT was lost and they're
part of a stable circuit. This seems to have caused some
sponge squeezers in particularly busy areas to stop for a
while when first loaded sometimes, which can interrupt
the water flow they provide, which can lead to a fire
hazard.
- On door convey
- On item ent settling
Only able to support limited cases, and still can't
usefully animate nodes, but at least this makes
some item placement behavior look smoother.
If something is blocked, store it in a separate retry
queue. If the thing that blocked it moved out of
the way, re-queue the things waiting on it for retry.
This is probably theoretically less efficient than the
old approach since it relies on finding opportunities
to move items on the fly and probably queues a
number of retries that will ultimately fail, but it's
simpler and easier to maintain than the old way.
The old logic was extremely over-complicated, in
an attempt to allow door conveyance to work with
no gaps and support loops. This led to code that
was unmaintainable, and a node deletion bug that
was too difficult to fix.
The drawback to the new approach is that things
cannot be pushed by doors into spaces that are
occupied by another thing, even if that thing will
be pushed out of the way by the doors on the same
cycle. This means that chains of items on
conveyors will always have an air-gap between
them.
Unfortunately this also causes conveyors to jam for
one turn if there is no airgap between nodes on
certain conveyors, but it's better than the original
bug.
The special case of trying to push a single item into a storebox
is an overlap between the item catapult and the place-node recipe.
Change the priority order so the catapult check is done first.
This is not expected to cause problems in other cases because in
those, the presence of a "backstop" node causes them not to overlap.
If two stacks try to move into the same spot at the
same time, both will be placed there and one will
overwrite the other; instead, we should do a check for
the "head" of a moving item chain (the only one that
can be moving into a space not being vacated by
another) and block collisions.
