Before, non-node items (tools and craftitems) were
exempted from opacity entirely and were always
transparent. Now, they use the same optic_opaque
and optic_transparent groups, are opaque by default,
and honor the sunlight_propagates heuristic (even
though this is rarely used for non-node items).
The following things were nodes that were defined as
sunlight_propagates = true but NOW will be opaque:
- shaftcraft items like sticks, staves, bars, rods, ladders,
frames, and torches
- flora such as rushes and flowers
- sedges, but only at max growth (make it now possible
to detect and automate sedge growth)
Instead of using variadics, hard-code array accesses for the
expected arity of door_operate_core, throwing away any
"future-proofing" that variadics were supposed to offer.
This is because in Lua 5.1, the length of arrays that contain
nil values anywhere in the sequence is apparently undefined, and
implementations are free to return the position of any value that
is followd by a nil, so length of {1, nil, 3} could be 1 or 3.
PUC lua seems to generally return 3, but LuaJIT takes more
liberties here (presumably exploiting UB for optimizations).
The problem arises when trying to unpack({1, nil, 3}) and LuaJIT
sees the length as 1 so return only <1>, instead of <1, nil, 3>.
This means that calling nodecore.door_operate(pos, ni, dir),
which was INTENDED for this API (it would look up node for you if
you didn't provide one) could result in the dir param being
lost due to packing the args into an array to defer them, and then
that array getting only partially unpacked.
Reference to WONTFIX bug where LuaJIT claims this is allowed UB:
https://github.com/LuaJIT/LuaJIT/issues/527
The solution for now is to stop relying on unpack (which is sort
of easy in its own way since I never really liked it). In the
specific case of nodecore.door_operate in particular, adding
more positional args (it already has 3) would be bad for other
reasons (should switch to a named passing style).
Some external rotation mods may change the way
node rotation works and put doors into a state where
they are one of the 12 "reversed" rotations instead of
the 12 "canonical" ones. Renormalize door facing
before processing rotations to ensure that these doors
are corrected automatically.
Deprecate the old APIs that used to close over the
metadata about valid node rotations. Now expose
this data in the node definition, and use a generic
non-closure function to handle the callback.
nodedef.spindata contains:
qty = number of allowed rotations total
cycle = table keyed on current param2 and valued with
next param2 for next rotation
equiv = table keyed by each possible param2 (24 keys)
and valued with canonical equivalent for that param2
...along with possibly other downstream bugs.
We had stripped the metadata off the wield item in the
pummel state tracking to make it so that changes to
wield item metadata (especially things that could be
changed by AISM while the player is using the thing)
would not cancel a pummel, but forgot that the wield
metadata that gets put into the pummel state is ALSO
fed to the recipe check. Use a separate key for this
stripped only-for-comparison version, and keep the
proper itemstack with full meta for recipe checks.
NodeCore will probably never use this itself, but it
can be used for mod content (i.e. Winter's waterlogged
containers) that will never allow infiltration of air
whether the sides are open or not.
While we don't need to include these in the .tr file, if the
translators verified that the translated string matches the
source string (e.g. lines with only a URL or other technical
information) it still counts toward translation completion %.
Optic checks follow a plan-then-commit phased process,
but ablation processing was happening (and modifying
the map) during the "plan" phase, which was almost
certainly the root cause of the optics duplication bug
that was just mitigated.
Add a mandatory "defer" function to the optic_check
protocol that nodes can use to peform additional
custom logic AFTER the commit phase has completed,
and move all door ablation actions there.
The "optic family" mitigation is left in place to also
provide a heuristic for verifying the problem has been
resolved.
Optic nodes are each assigned a "family" of nodes that
are equivalent things with different power states. Optic
commit is not allowed to replace any node with another
node outside of the source node's family. This at least
prevents optic_commit replacing an air node with an
optic node (the way the dupe manifests). Log a warning
whenever this happens.
Unfortunately we still don't yet know the actual cause of
the problem, so this is just a workaround, not an actual
fix.
All rotatable node selection boxes should be as symmetrical as
possible so that rotating a node without moving the cursor won't
change which node the cursor is pointed at by resizing the
rotated selection box out of the way, which can cause repeated
right-clicking to miss and hit another node.
Prisms were corrected for this some time ago. Lenses were
apparently close enough that this was missed, or considered not
important enough, but this change makes things much more
consistent, including making the lens and prism hitboxes match.
Show a textual fuzzy description of how long a player has been
offline (in terms of in-game time, not realtime) in player ghost
looktips instead of just "Offline Player", if the last seen time
is actually known. Can be disabled by a setting.
When placing an optic node into an existing beam path, it
immediately acquires the correct state rather than being placed
as "inactive" and needing one tick to activate. This would cause
a "down" pulse to travel down networks when placing a "vampiric
tap" into an existing beam path, even if it was placed with the
correct initial rotation. This reduces a source of noise in
optic circuit building that doesn't appear to add any meaningful
challenge, only nuisance.
Prevent stack from doing selection-reanimation
by just setting the time at which annealing would
happen once rather than keeping a count of
elapsed time.
The builtin grant/revoke commands modify the privs table returned
from get_player_privs, which can poison the cache if the priv
modification is later aborted due to an error. Return a clone of
the privs table instead so that modifications of it don't affect
the cached copy.
If the transformation happens at the player's actual
location, they don't have to "see" it if they can "feel"
it. This fixes witness triggers happening inside the
player's inventory.
Note that these are separate from the existing
recipes used elsewhere out of necessity. Lode
also anneals faster when carried (it's exposed
to more air cooling).
- Pick up and carry hot lode things
- Sane tool wear management
Known Issues:
- No recipes yet
- Glowing things don't anneal/temper when inside
player inventory
Door press and plank recipes now share the same
underlying logic for checking for a "backstop".
Refactor the recipe checks a bit more to get rid of
excess structure and named functions.
After successfully moving a node, always stop trying
to move that node to another spot, regardless of
whether or not we had any retries to process as a
result.
Rotate horzy and verty etched concrete around its vertical axis
when it's placed. This only affects the direction of the stripes
on the top and bottom of the blocks. For example, a cross-beam
made of horzy concrete can now have the stripes on the top and
bottom of the beam in the same direction as the stripes on the
sides, or not, as desired, where before the top and bottom stripes
always ran east-west.
