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.
Treat all "stone-like substances" as stone for purposes
of the hints. You can chisel/bond any of stone, adobe,
sandstone, tarstone, etc. to get credit for the hints, so
there should no longer be hints hidden because you
haven't had the exact right kind of unetched concrete.
When this was setup, it was named generically
in order to support future functionality that
used the same heating/tempering/annealing
mechanics. Ironically this has actually only
caused problems.
Standard game mechanics will not mimic one
another, especially something this complex.
Anything worth making a system for nodecore
that's as complex as lode-working deserves its
own distinct mechanics rather than recycling
lode-working. So vanilla NC will not reuse the
metal-working logic anyway.
Mods were able to reuse the existing logic, but
ironically the only one mod that would actually
have benefitted from it (i.e. uses very similar
heating/tempering/annealing) just copied and
pasted the code from NodeCore anyway, which
not only didn't take advantage of the existing
mechanic provided, but actually made the mod
break the game when installed, because the
mod would replace functionality in use by
vanilla with an older version, and the copying
will always keep that functionality locked in to
an older version, breaking whenever future
changes to the base mechanic are made.
Rename the base mechanic to (1) get out of
the way of the existing mod, and (2) make it
more clear that this is NOT generic functionality
that can be used to create new metals, but
only specifically for lode, and if somebody else
wants a clone of this logic, they would need to
rename it to make sense.
Witness checks include data about the node in
place at the time that the witness even occurred,
so players are not awarded credit if the node they
see there was changed again afterwards. A lot of
old witness code inserted the witness right
before the node was changed, since the node
change was done as a tail call, but this does not
work with delayed witnessing because the
delayed witness data would be tied to the old
node, not the replacement one.
Moving witness to after node setting should fix
a number of broken hints that should have been
delayed-witnessable, e.g. brick bonding.
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.
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 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).
Get rid of the intuitive leap necessary to climb a
tree to make planks. Instead, a wooden adze
can be gravel-tipped (adzes are now represented
in all tiers) and can chop tree trunks.
The graveled adze is as powerful as a wooden
hatchet and spade combined, in terms of
diggability, but it breaks after a SINGLE use.
It doesn't consume the gravel it's made from,
but reapplying the tip each use is a lot of extra
process.
- 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.
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.
- Move hint handling down to API layer
- Simplify stat data; old nc_stats counting can
be moved out to a separate mod. We only
need whether the player has seen or not.
- Invert inventory tab responsibility.
- Merge witness system in from crafting.
TODO:
- Redistribute hint registration responsibility
to individual mods.
- Test external mod compat.
- Retire old nc_stats and nc_guide systems.
- Add a way to reset hints.
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.
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.
- Original texture by WintersKnight94.
- Node definitions and recipes adapted from original.
- Added some hooks in a few other places to make new
recipes work.
- Chip smooth stone with a lode pick or better to make brick.
- Bricks fall but don't repose.
- Apply mortar (wet aggregate) to bond stone bricks
- Bonded bricks can be moved but don't fall anymore.
Treat all API mods as a "layer", and use the new
nc_api_all registration to indicate that a mod depends
on the NC API (which ALL NC mods assume they do).
This means that each non-API mod does not need to
worry about which API mods it really needs and which
it does not, nor will they need to be updated for any
internal API restructures.
This is a game, not a modpack, so all mods will be
loaded anyway, and we only care about order. That
means that we don't really need to worry about
having excess dependencies because any mod we
don't actually need will be needed by something that's
loaded anyway. If somebody wants to reuse a
component elsewhere, they're likely to need to do
some work to untangle it anyway, because of the
amount that NodeCore mechanics interact and
interdepend.
Stone, lode, and lux tools now all have their handles burn, and
eject the non-flammable portions of the tool.
Now using a unified on_ignite hook for when flammable things catch
fire. The call is made BEFORE the node is replaced, and has an
opportunity to look at node metadata and eject anything
non-flammable.
It can be a function, e.g. for shelves, or a static value in the
same format that the function would return (e.g. for lode tools
which need string values for temper substitutions).
If it returns a string or itemstack, it will eject that from the
position where the node burned. If it returns a table it will
eject all the values of that table.
- Collapse all nodecore "core" mods in the /mods listing, so it's
easier to find the actual add-on mods.
- Parameterize in-game branding to make renaming derivatives just
a little easier.
