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.
This reverts commit 253c2282917ecade5b8356d592edab40b1d517f5.
Apparently this warning is full of crap. Explicitly
setting use_texture_alpha in the node def does
something DIFFERENT than what the engine says
it's doing enabling it internally. use_texture_alpha
enables alpha BLENDING, which is what we
don't want with interpolation filters, whereas
leaving it off enables alpha THRESHOLDING which
is exactly what we want.
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.
Apparently we will be required to enable
use_texture_alpha explicitly for anything using
any level of transparency, not just alpha
blending, in some future version.
Hughes Ross has started to work on a PR for this
(https://github.com/minetest/minetest/pull/10140)
but it doesn't look like it will be ready until 5.4 at
least, and we will support pre-5.4 versions for
some time yet. The ability for TP artists to
override special_tiles is necessary to allow things
like flowing liquid textures to be customized in
texture packs.
Add a hack for these, similar to how we did the
inventory/wield image hacks.
Note that we are also forcing overrides for special
tiles, since there may be cases where we reuse a
base image without modifiers but TP artists may
still want an independent override.
Apparently this interacts badly with
optomechanics when multiple optic
tick cycles are running on a single
globalstep, since it may cause doors to
miss signals if they quiesce back to
off during the step.
Instead of limiting the number of cycles
to some arbitrary upper bound, run as
many cycles as necessary up to a CPU
time limit, i.e. we only allow expansion
of globalstep time by a fixed limit.
If we're running multiple optic ticks in
rapid succession, then we don't return
control to the rest of the game between
ticks, so there's no point in reading the
map more than once per pos, and no
point in updating the map until the end
when optics may have oscillated
across multiple states.
Maintain a cache and commit buffer
during each globalstep and only flush
them at the end.
Apparently as oilboi pointed out, node metadata
is kinda gross, and in this case we didn't actually
need it, since the information could actually
always have been inferred from the nodes
themselves.
Instead of storing output state in node meta,
just register a callback on the node definition to
interrogate the node itself about its power output.
By restricting the recipes we check based
on the name of the central object being
checked, we can do many fewer craft
checks per item and avoid expensive
checks.
Register a "rootmatch" property for all
recipes that represents a broader, quicker
test for recipe eligibility. False positives are
allowed but false negatives are not.
Since most recipes are eligible, we can
use this to build an index for fast lookups
of subsets of recipes to run and skip most
of the other ones.
