Also, if somebody really wants to make an API-compatible "default"
mod that works on top of NodeCore to allow MTG mods to work with
NodeCore or something, that's fine too.
Players still need to enable some settings:
- Enable shaders in Settings
- Hunt for "auto exposure" in advanced settings and enable it
The game will try to adjust the brightness automatically based on
the local light level. Unfortunately there are problems with it
(e.g. it seems to detect light based on the light level where you
are standing instead of where you're looking) but it may help
improve the "caving" experience without having to mess with gamma
curves.
Note that if the exact wording of a hint changes, then those hints
may be pushed to the top of the list. This is an internal
limitation and cannot be prevented without assigning some other
stable unique identifier to hints (a lot of work and probably not
worth it for now).
A tiny amount of timing jitter is applied to hint discover time
(<1ms) to ensure that hints are always in a stable order.
Hints are identified by a short hash of the hint text, so it is
also possible (but unlikely) to have collisions that cause
hints to sort earlier in order than they normally should.
Using the new API, it is now possible to register custom logic to
operate on a node drop list at each time a node is dropping its
drops, in list form, before they're processed into the player
inventory or into entities.
This can be used by a number of the "add extra drops to ores" 3rd
party mods like WC Adamant, YCTIE, and LuxGates, to add drops to
existing ores *without* overwriting other mods' changes.
Sometimes sponge squeezers are built too close to a mapblock
boundary, and rarely fail due to the artificial water being
loaded but the lens powering the squeezer being unloaded or
inactive. Try to detect these borderline cases and prevent the
water from disappearing. It would be somewhat unfair to expect
players to predict and prevent this failure mode, especially in
certain high stakes play modes like skyblocks, so try to prevent
it if we can.
While remaining compatible with the old functionality
(we allow registering craft recipes at runtime,
whether this is really sane or not), significantly
reduce the number of craft index rebuilds we do, to
only up to one per tick, only when new recipes have
been registered. This should be fine because no
recipe should be actually used until at least one
tick after it was registered.
One potential source of the "missed item registration" bug could
be the on_register callback running multiple times for an item if
it was registered during a retroactive on_register scan. The
behavior of pairs() if the table being iterated is modified is
apparently undefined. In fact, it may be possible for a table to
get rehashed, such that some items might be skipped. Taking
a snapshot first and iterating that instead should be more
stable overall.
This was done for doors in operate.lua, when
hash_node_position caused all sorts of problems,
including freezes. Never did actually figure out
WHY, but the change worked there. Since door
ablation is suffering its own reliability issues,
maybe it's time to try that change here too?
