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.
- Anvil API is a wrapper that registers multiple
recipes, one for each type of anvil allowed.
- Can now use smooth stone as an anvil, however
once it's been used it cracks, and once it's been
cracked, if it cools, it converts to cobble and cannot
be reused, forcing players to master concrete, keep
their forge hot, or relocate the forge each time it
cools.
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.
- You can now forge hot lode using either tempered OR
annealed anvil.
- This creates a gameplay path for accessing annealed
lode without having the resources (i.e. water/sponges)
to access tempered yet.
- Cold-working is still more efficient for being able to
pick up the excess prills from the process.
- Cold working, and then heating afterwards, is still likely
the only reasonable way to make mattocks.
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.
- Make node match operate on only one of node or stack, depending
on whether node defers to stack via is_stack_only. This should
hopefully prevent future pummel recipe issues.
- Add new core stack API. Needs to be deployed in a lot of places.
- Start work on system for allowing flammable containers; they
eject their potentially non-flammable contents.
