- Unify logic for expanding nodenames/itemnames lists into indexes
of matching names, and comparing item names/defs to lists,
with group expansion and deferral.
- Add "autostart" option to DNTs which registers construction traps
and a patrol ABM automatically, use for some things that are a
good match.
- Note that some things are doing more complex logic in ABMs, such
as determining if a node is eligible, or custom timing logic;
leave these as-is for now.
- Run all settings through a common API.
- Use modname prefix consistently for setting
keys instead of "nodecore".
- Add automatic dumping of settingtypes.txt
metadata for maintenance.
- Include initial settingtypes.txt for game for
main menu use.
- Remove per-recipe tuning for pummel recipes,
as there were way too many of those to be
possibly useful and it was clogging up the
settings menu. Use tool rate adjustments to
control it instead.
- Remove vestigial enable_damage setting.
It was checking the craft before actually placing
the node, causing the crude glass recipe to
complete when molten glass flowed into a mold
with water below, then it got replaced by the
source node, then it re-quenched to chromatic on
the next ABM pass. Now it actually quenches
directly to chroma immediately like it should.
As soon as an item is placed run a cooking recipe
check, so auto-furnaces can run at maximum
designed speed instead of having to wait for ABMs,
which may lag. This should make MP performance
also a lot closer to SP performance...
Instead of checking for and immediately
completing a craft, the API can be told to
search for a recipe and return a function that
can be used to commit it later. This way,
we can search for a valid recipe during the
"check" phase of a craft check and then
commit it during the "after" phase.
If a player is close enough to an event when it
happens (withing "likely hearing" distance) then if
they later punch the node then they can "collect"
the discovery.
The idea is that if a player hears the sound of
something happening, then they might go and
investigate and discover the thing they thought
they had left there isn't what's there anymore.
In retrospect I may want to combine this with a
limited form of the visual witnessing, just as there
may be events that a player is less likely to touch
in aftermath, or may not be practical to (e.g.
if what's left behind is air)
- 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.
- Merge the "legacy, could be anyting" sets
into every other set so we can do only 2
set lookups instead of 3.
- Make sure we don't do any duplicate
recipe checks.
N.B. the craft priority order MAY be different
now, since primary node recipes are
checked before visinv stacks.
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.
If the item type does not at least pratially match any cooking/cooling recipe the first run, assume it never will and cache this fact
so we can quickly skip all stacks of the same
item next run.
Bug was introduced in 16a7c9fe, caused by
the fact that sometimes nodes are dug by nil,
i.e. the way the chisel is dug up automatically
in the chiseling process.
- Register groups for chiseling doors.
- Make recipe digging not use player inventory, but drop
as an item unconditionally. N.B. the old "replace with air
then drop item" method only worked with explicit item
names and not group detection.
This created a ton of dependency inversions, which
necessitated moving a number of API functions up into
higher layers, and restructuring dependency lists for
a number of mods.
BOLO: non-deterministic load errors due to missed
dependencies.
Many processes that have a significant speed/time component can
now have speeds adjusted (as a multiplier from base rate) via
settings.
Things that can be adjusted:
- Tool speeds (including digging and pummeling)
- Cooking and pummel recipe durations
- Soaking processes like tree growth, peat fermentation
The settings are hierarchical, so groups of rates can be
adjusted together, and a further multiplier can be applied to
each member of the group.
The settings are calculated dynamically, for power users only,
and documenting them is out of scope for the project.
Specifically, this should help tuning for Kimapr's SkyBlock, and
possibly other mods involving signficant gameplay rebalancing.
Use high-res version in a few places we were using integer-res
timer before. This should e.g. smooth time variation of wind
strength for ambient sounds.
- Make handhold nodes glow, to visually simulate the player
character's now "familarity" with them by feel. We have to
represent it synesthetically because the game only gives us
sight and sound to work with.
- Make floors "scalable" so that they glow, even though they
don't affect maneuverability.
The effect of this is to allow a player who has fallen into a dark
cavern to navigate, slowly, by feel, allowing more extensive
self-rescue possibilities.
- 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.
