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).
Sponges can "time out" due to having been unloaded, and having
their check timer fire before an automated squeezer door timer
fires. If this happens, the water needed to drain completely
before it could be re-squeezed, forcing a break in the water
flow.
This allows water sources to replace the water flows, so that
unbroken water sources will work even in load/unload boundary
conditions.
Lock more things behind prerequisite hints, even if
they're not absolutely strictly necessary to complete
in that order, if they would commonly be done in
that order. This reduces players being overwhelmed
by available hints very early in the game, and avoids
red herrings like "find lux" which can technically be
accomplished but yields no useful results until the
player can act on them.
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.
This was triggering on all dirt nodes everywhere, so optimize the
most common code path, i.e. one where there is no water above
and the soaking data must be reset.
These cause some issues, like the ability to soak
dirt under water for a short time to initialize the
soaking metadata, then remove the water flow,
then add it in and have leaching complete instantly
because the neighbor check prevented the soaking
ABM from firing to detect that the water was
removed.
In the course of investigating why ABMs are so slow
to begin with, it was discovered that having neighbor
checks can slow an ABM down by a factor of something
like 7x, so clearly the assumption that the neigbor check
being done in C++ as "efficient" was false. This means
that we may be better off just always firing the ABM and
letting Lua check only a couple of relevant nodes (e.g.
for water flows in the space above) instead for
performance.
The main performance concern was dirt leaching, since
dirt generates naturally in the world in bulk, but if the
single check for water above may be faster than checking
all 26 neighbors in C++ anyway, we might as well let the
soaking API run for it so that it can detect the water having
been removed and reset the counters.
- Fix stone detection so they actually generate
- Buff pumwater frequency 2x, to 1/4 water
- Try to enqueue liquids for flow transform as soon
as the mapblocks are loaded
- 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.
Now nodes other than sponges (i.e. downstream
mods) can create artificial temporary water sources
similar to sponge squeezing.
The API allows specifying a source node and position,
so the water will dissipate if the source node is
removed. A min/max TTL can also be specified, so
like the sponge, it can require external triggering to
maintain the water flow as well as the presence of
the node.
The original theory was that preallocating the array forced lua
to use the "array part" of a table instead of the "hash part",
which should be faster since lookups are a simple linear offset
calculation and not a hash with collision check.
It turns out, however, that in empirical testing, whether the
array-preallocated or the naive-allocated version is faster depends
on circumstances, such as how sparse the array is, how uniform
access is, or how much other load the system is under. This seems
to suggest that arrays are more computationally-efficient but less
cache-efficient, so cache evictions caused by other concurrent
processes may slow this method down significantly.
Worst-case performance will be the most noticeable here, since a
system that's heavily loaded would have the most need for speed
in the first place, so it's probably better generally to use the
naive allocation.
In all, the naive allocation method also seemed to be the least
sensitive to external factors. In addition to the array method,
attempts to pre-compile the dynamic checks into a binary tree of
if/then statements (which could be JITted and optimized) failed
as well.
It doesn't catch 100% of everything, but presumably
it catches at least some things, and has little
marginal cost on top of the ABM alone.
Players have been remarking about the fact that
dungeons sometimes initialize right before their
eyes. LBMs SHOULD be able to fire outside of the
ABM active range, giving us a chance to catch these
a little earlier before the player is close enough to
notice...?
Apparently on top of dungeons regenerating
over top of themselves, caves can also carve
into dungeons, and this may cause issues
with dungeon loot, where the loot nodes are
removed (but w/o the destructor) so that
floating fake visinv entities are sometimes
left floating in place.
Instead, give the engine time to finish
initializing dungeons, and then use only the
ABM (sigh, it's always only ABMs that are
actually eventually reliable after all) to do
delayed initialization.
This kind of sucks if the player starts out in
a dungeon in a new map, but the old "fast"
methods weren't fast enough to prevent a
flash of uninitialized dungeon anyway, so we
just have to hope that the dungeons will get
initialized while on the map horizon before
the player gets close enough for it to matter.
Get rid of the different dungeon cobble now
to mitigate this, also since we no longer
need it to debug uninitialized dungeons.
Mods can now nodecore.register_dungeongen(def)
similar to how mapgen_shared works, except func is
run for each (pos, node) in dungeons. This tries to
catch all dungeons as soon as possible, but some
nodes may experience arbitrary delays before
they're processed. We hope this won't be a problem
in practice because dungeons should usually
generate on the periphery of view range and have
plenty of time to process before they arrive at the
player's current location.
This API could be used in theory to customize the
materials used in dungeons or add treasures.
- Add reset command
- Reset alerts on resetting state
- Add option to hide hints
- Add option to add custom hint attrs
- Add option to pass in an already-fully-formed
hint object and skip construction helpers
- Tidy up terrain hints a bit
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.
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.
Two optimizations that added up to a significant
time savings in on_generated:
- Replacing calls to area:index(x,y,z) to precalculating
an offset and then using stride math inside the loops
gives us a huge cost savings.
- Prefilling lookup-by-ID tables to force them into
sequential arrays instead of hashmaps speeds up
lookups, for a more moderate savings.
This should cause maps that have the same
seeds to have much more similar results
than before, e.g. sponge deposits will be in
the same places determined by seed and not
random each regeneration of the map.
- Mapgen shared now provides an RNG which
will be deterministic when feasible, for
repeatable mapgen results.
- Make existing rng-using mapgen hooks use
the new deterministic RNG.
- Mapgen shared hooks are also run in
deterministic order too.
- Tidy up mapgen_shared API a little more.
Stone is hardened by creating an elecric field via the Peltier
effect that causes internal crystals to align. Or something like
that.
Stone hardens over time when touching both lava and water.
All stratafiable stone types (lode sign, lode ore, lux ore) are
affected.
Don't reuse damage_per_second for damage on punch and radiant
damage. This allows these to be defined separately, i.e. no longer
assuming that all damage is from "heat" and can radiate. This
allows for things like thorny plants that hurt if you touch them
or stand in them but not if you stand near them.
Thanks to WintersKnight94 for reporting this.
