It was always weird that the player character could
sense hinged panels even when the faces shown were
completely undifferentiated from their non-panel
counterparts. Add a fairly subtle visual indicator that
makes it obvious why the player can spot them.
Players can still hide doors in plain sight, they may
just need to take more advantage of shadows and
other geometry tricks to ensure they don't stand out
against a field of similar nodes, or use psychological
tricks to distract other players from spotting the
patterns.
- 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.
- New near_unloaded API that supports custom
distance parameter, map bounds check, and
some optimizations.
- Add area automatic unload check support to ABM
API and add to applicable ABMs, replacing many
old manual checks.
Note that the explicit unload check is only strictly
necessary when something will happen due to
a node NOT being present in the area, e.g. something
igniting due to absent coolant, or soaking quantity
being reset due to missing sources. In simple cases
where the absence of a thing causes the ABM to do
nothing, then the standard check can work because
the default action is to do nothing anyway.
This is a design compromise to knock out the
worst offender in ABM cost, by requiring a node
that must be created by player action instead
of ubiquitous naturally-occuring nodes that all
need to be checked.
Leaching is really meant to be more of a minor
gameplay element anyway, for either skyblock
purposes, or for people who are bored enough
that they want to take on a challenge like a
neutral eco footprint; most normal players just
gather the materials from mapgen and hardly
bother with leaching recipes anyway.
This reverts commit b1661c976e3a6420c3917a5322ee72e0dd9ddb6d.
This was done inconsistently and the problem extends to a number
of nodes, which should probably all be fixed at the same time.
Add grass root texture to underside (and visible part of dirt
on sides) of grass node. The difference in node sounds but same
visuals was always an inconsistency, and since touchtips became
looktips, players being able to distinguish grass from dirt from
the underside didn't make sense without an actual visual
difference.
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.
