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.
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.
Thanks to Kimapr for the basic approach, and proving
the concept.
Doors pressing a single-item stack now place that
item as a node, and trigger placement recipes. Doors
pressing nodes that don't have a single item stack
node form (sticks, leaves) also trigger placement
craft recipes.
All craft pressing recipes require some form of
backstop to provide pressure.
Hints themselves have not been tided up
much, but this makes the project of fixing the
hints for each mod a little more manageable
and breaks up the hard-to-navigate single
monolithic hints file in the old guide mod.
The old guide mod has now been completely
retired. Hints are now a full-fledged API-layer
standard feature.
