Instead of relying on base layers to replace dungeon cobble with
real cobble in the bricking logic, explicitly set a cobble node
name so that downstream consumers (e.g. nature mod) that extned
this API will reliably get all fill/brick/bonded members of the
material profile to transform consistently.
Use all base concrete materials in dungeon gen.
- From y=+32 to y=+64, transition from stone to a 50/50 mix
of adobe and sandstone.
- From y=-640 to y=-768, transition from stone to tarstone.
Adds some more variety and reason to explore dungeons.
Add a generic method to get stonework materials for dungeon
brick generation so we can extend dungeon bricking while keeping
the same pattern of mixed cobble/bricks/bonded.
Some loot does not appear above certain depths, to restrict
late-game content to players who are more likely to have actually
achieved that level, and not spoil very-late-game content very
early in surface-accessible dungeons.
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.
This document has remained unmaintained for a
long time, never was truly correct, was always
reactive and descriptive rather than being
prescriptive, and frankly the readme does a better
job of that anyway.
From early on, NodeCore was always about
experimentation, and just keeping what fit in and
worked. This means that "design principles" have
always been less about some grand underlying long-
term vision, and more about just pattern recognition.
NodeCore has been around long enough that the
patterns are fairly evident by now. Trying to keep
around a doc that is always lagging behind these
patterns is not helpful.
Simpler, fixed-probability-based, mutate into
nearby phenotypes only. Mutation rate is
greatly reduced, should make flower breeding
into a challenging idle minigame.
When placing a tote, if the space it's being placed into is not
buildable (e.g. placing against the ground where a stick is
lying above it) then it would crash; make it just abort tote
placement instead.
Turns out the only major use of particles was
a unified smoke generation system.
In theory sound could be limited too, but there
maybe some risk in delaying it (in case
globalstep flushes run before the sound-causing
events) or losing sounds affecting accessibility.
Standardize a "fair limiting" mechanism that
limits the items accepted into a queue, and
returns a uniform random sample when flushed.
Pass all cooking/curing smoke effects into fair
limit queue.
Apply fairl limit queue to fire sparks too.
Pliant concrete curing checks still seem to lag
the server somewhat, but at least now they
shouldn't hammer the client with particles and
kill framerate too.
If a player loses interact after having discovered
things, then logs out, then later relogs in without
interact privs, it will not load the correct already
seen alert cache data on join. This causes a
swarm of hint alerts to appear when interact
privs are restored. Instead, detect when interact
is freshly re-granted and reset the cache at that
time automatically.
Player can trigger looktips by standing still
for a while (looktips on everything instantly),
by holding focus on a specific face for a
while (looktip just on that one face), or by
punching (instant looktip for that one face).
Right now looktips are rather obtrusive to
the overall game experience, and should
show up on some kind of delay to mitigate
this.
I tried having a delay for looking at a node
before a looktip showed up, but it felt sort
of annoying when switching from node to
node, especially since the faster response
on the face-dependent location of the tip
is helpful for building. The code for it also
turned out to be messy, since node and
object handling needed to be different, since
it was unrealistic to actually hold the
crosshair on a moving thrown object.
What I've got for now is just disabling the
looktip during, and for a slight delay right
after, any player movement, based on
movement input controls. This prevents
the player from having a bunch of looktips
juddering across the screen while walking,
but allows them whenever standing still.
This MAY be good enough, but it may take
some play-testing to confirm.
Need to be granted interact privs before they can
start observing and discovering things and trigger
hint completion. This should reduce the noise for
pure spectators, and not distract new players who
should be reading rules or something.
The "player character" only assists with "depth
perception" and determining if pointing at
something within reach; diggability, protection,
and other consequences of touching the thing
should really be the actual player's responsibility.
We don't want things to be too "automatic" for
the player; they are supposed to learn about the
world, not about the HUD instrumentation.
The use of object vs node crosshair is less important now
due to our ability to rely on the looktips to differentiate
which thing we're pointing at (and which face), and
makes less sense in terms of NodeCore's everything-is-a-
node nature.
Protection, however, is more useful to show, where in
use, so players can avoid interacting with things and
triggering protection alerts. Use the old everted
crosshair design to now mean "protected" instead of
"pointing at entity."
The old use of the crosshair shape should have been
uncommon enough that players should be able to
adapt to the change alright.
- Tab content can now be "raw" instead of plaintext, in
which case it will not be escaped or embedded in a
textbox and can have arbitrary controls.
- Tab content function is now passed geometry that
would be used for textarea, to inform placement of
custom form controls.
- Tab content function is passed list of current
formspec content in mostly-complete form, so that it
can modify any other form data, including replacing
the entire form if it wants.
- Falsy tab content (or content function return) prevents
showing the formspec at all, allowing mods to show
their own formspec entirely, but navigation back to
the guide is the mod's responsibility.
Instead of sorting hint completion alerts alphabetically
just so they'll be stable, sort them by order of actual
completion, so most recently completed hints are at
the bottom of the list, instead of inserted at randomish
places in the list.
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.
