Looking into the possibility of making everything
overridable for game-logic purposes by group, it
turned out to be a bit of a nightmare. Also, instead
of overriding them at the "heuristic" layer, it's
probably better to simply allow overriding at the
specific game logic level, e.g. so that multiple
systems that use the same source data for heuristic
purposes can have differing behavior.
- Smoke API uses expandable options param instead of positional
- Separate burst qty from automatically adjusted rate
- Backward compat with old API for now
- Standardize burst of smoke puffs for crafting
- Torches emit small smoke particles at increasing rate as they
start to wear out, to warn players holding them to light another
- Torches now emit a puff of smoke upon snuffing
If there's any coolant near a node, that blocks
all application of heat and prevents it from being
cooked, and also prevents any passive slow-cooling
recipes from operating on it (i.e. racing against
the quenched recipes).
Use coolant neargroups for quench check too,
for consistency. Add memoization to the recipe
data on the check, so to avoid doing the quench
scan for each recipe separately.
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).
- 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.
During processing of the flammable ignition ABM,
nodes could ignite, causing the new ember nodes
created by this ignition to trigger fire propagation
instantly during the same tick by nodes still yet
to be processed for ABM checks during the same
scan. This often caused large areas of flammable
nodes, like wooden plank skyblocks, to be ignited
instantly in a specific direction from any source
ignition. This led to some "cheap shots" where
players were ruined by fire far more rapidly than
they should be.
Instead of processing flammability checks in
sync, delay them until the next tick, so that we
find all flammables to check before any new
igniters are created. This should tame fire
spreading back down to normal levels.
Instead of digging the glue off by hand and freeing
up the optic to rotate again, it must be fully dug by
a tool, to further prevent accidental ungluing.
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.
Finally use the new Forms to craft shelves
using a 2-component recipe, and replace the
old 3x3 recipes. This affects:
- Wood shelves
- Clear glass cases
- Float glass cases
- Lode crates
- Tote handles
For now, we're just going with the simplest
recipe of just putting an item into the form.
If players want to store things in the form
without assembling a shelf, they'll have to
remember to drop items in through the top
only.
Forms may have served a purpose as makeshift
storage when actual shelves are too expensive
but this is NOT their purpose. They are
primarily intended as crafting ingredients for
proper storage, and secondarily as hoppers for
stack-fed machines. Any ability to use them as
actual player-controlled storage devices is
purely coincidental and not guaranteed.
Lenses enter a "glowing" state to propagate signal
immediately as before, but now they don't actually
produce light until powered steadily for 2 seconds.
This should mitigate the risk of "strobe" circuits that
cause excess lighting recalculations and irritate some
sensitive players.
This caused copious confusion for new players, who assume the
glass "tank" is like an aquarium tank and can be used to carry
water. Originally it was intended to seal in "moisture" for
sponge transport, but that has become a far less important use
case (and in fact sponge transport is probably best done just by
building submerged pathways, like the way amalgam transport is
done) and glass "tanks" are more like "display cases" now, or an
intermediate storage container that adds top access (useful for
totes).
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).
Any liquids that are dropped should become
placed nodes. It was observed before this that
wet concrete may have been displaced in such
a way that it created a stack node; this ensures
such things are precluded as much as possible.
The game was designed with this appearance in mind, especially the
appearance of float glass, and having this turned off can have a
major impact on the aesthetics and even function (accessibility)
of builds.
The ability to enable/disable connected glass is of unproven value
even to lower-end systems, as most of the additional work is in
the background mesh-building thread, and by now the game is complex
enough that other factors completely overpower the impact this has
on performance.
Forcing this mitigates the risk that players who have connected
glass turned off will not experience the proper results of using
float glass, and that their builds will appear very different for
other players.
- New fluid wandering API, mostly unified logic, only needs
some parameters, plus the "generation check".
- More sophisticated behavior seeking down-slopes beyond simple
immediate flowing node reach ("subtle slope" detection).
- More reliable timing using DNTs.
- Set firm movement rate of concrete, molten glass.
- Reduce molten glass generations, since it can now be more
reliably directed.
- Run all settings through a common API.
- Use modname prefix consistently for setting
keys instead of "nodecore".
- Add automatic dumping of settingtypes.txt
metadata for maintenance.
- Include initial settingtypes.txt for game for
main menu use.
- Remove per-recipe tuning for pummel recipes,
as there were way too many of those to be
possibly useful and it was clogging up the
settings menu. Use tool rate adjustments to
control it instead.
- Remove vestigial enable_damage setting.
- For inventory and wield images, this is already
possible via override.txt since 5.3.
- For special tiles, this will be possible in 5.4.
- This complicates things, and introduces warning
messages into mods built without awareness of
this feaure.
- As far as I know, no texture packs have actually
ever used this feature.
The old system effectively cached cross-block
boundary information forever and never expired
them, even if the node creating them was
removed (that would have been easy to fix) or
an obstacle placed in the path (that would have
been difficult to fix with the old method).
Instead just do the simplest thing and split this
into a separate loop, and run a 2-second DNT with
a separate forward-trace from all active optic
nodes.
Doing a second forward trace for each node output
may not be as efficient but ultimately we create more
problems than we solve when we try to be too clever.
Wherever an optic beam strikes a mapblock boundary,
it now creates a particle effect visible to players close
enough. This can be used to plan circuits so they work
entirely within a single mapblock and thus are never
internally interrupted by unloading.
