We were using action log level for a lot of
things because by default MT does not seem
to capture info logs to stderr. On "production"
servers though this makes too much noise and
makes it hard to find actual player actions.
Servers that want info logging will just have
to configure/compile it in.
- Flexible discovery list format for discover and
witness APIs
- Add "discover" key to recipes that contains a list
of discoveries to give players so they can act like
recipe groups and allow different recipes to
complete hints
Recipe group system should be easier to setup for
hints than having to list all hints individually. We
can use them especially in recipes that are loop
generated.
Cooking recipes run in all visinv nodes, not just
item stacks, BUT non-stack-only nodes (i.e. all
storeboxes) block flame touchgroups so things
in boxes cannot be heated/melted.
This allows items dropped into boxes from ore
melting to cool, but prevents sand from being
melted in a box which would naively replace
the box with the molten glass entirely.
This also fixes an old rumored bug where forcing
glowing lode items into a shelf with a door would
cause them to stay hot indefinitely.
N.B. lode cooking/cooling used to assume it could
replace the entire node, and deleted the thing
as a fail-safe when an item of the given temper
was not found (e.g. tools w/ handles). This is
now gone, and invalid tempers will throw errors
if they can ever be achieved in practice.
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.
- 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.
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.
This makes it a little easier to discover recipes, since you now
generally don't have to get the exact count right anymore; just
make sure you at least have enough.
Appears to work with existing functionality.
Next step will be to rework pummel to use a "recipe" system and
reuse most of the useful parts of the crafting system.
