It's possible multiple soaking ABMs are registered
against a single node, and if this happens, make sure
that the qty and time fields in the cache are kept
separate the same way they are in the node meta.
- Removes repeating patterns, creates a richer and
fuller sound experience
- Larger areas fill sound volume out better instead of
just repeating more loudly
- Spread network traffic across multiple ticks better
to reduce packet spikes
Each node position has a set delay, between 0 and 1
second, that's fixed for that pos but varies more or
less randomly between positions. This ensures that
sounds loop with the same frequency and alignment
for a given single node, but desync across nodes.
Instead of statically-positioned wind sounds, many
of which are often outside of hearing range,
attach sounds to moving entities which often tend
to move across the player's position.
Instead of queueing inverted ABMs and then running
them out-of-band, run them inside the normal ABM
schedule time. This should:
- Prevent ABM mux lookup problems caused by nodes
changing after a delayed inverted ABM schedule and
the action actually running
- Allow the ABM scheduler to better account for the
time spent running inverted ABM actions, to ensure
that they properly count against the default 0.2s
ABM runtime budget and can't spike lag up higher.
This reverts commit b1661c976e3a6420c3917a5322ee72e0dd9ddb6d.
This was done inconsistently and the problem extends to a number
of nodes, which should probably all be fixed at the same time.
Lenses enter a "glowing" state to propagate signal
immediately as before, but now they don't actually
produce light until powered steadily for 2 seconds.
This should mitigate the risk of "strobe" circuits that
cause excess lighting recalculations and irritate some
sensitive players.
Add grass root texture to underside (and visible part of dirt
on sides) of grass node. The difference in node sounds but same
visuals was always an inconsistency, and since touchtips became
looktips, players being able to distinguish grass from dirt from
the underside didn't make sense without an actual visual
difference.
This gets rid of the 5.4+ "deprecated get_player_velocity" warning
and modernizes the code to use get_velocity() everywhere, while
still remaining compatible with 5.3 for now (tested). The polyfill
had to be on joinplayer because the nc_player_pickup auto-one-time
method of using after() won't reliably patch the player before some
other globalstep tries to read player velocity.
When MT 5.5 is released and 5.3 support ends, the polyfill just
needs to be removed to clean it up.
Also tidied up and consistentized the logging for other hooks.
Check for a dig recipe first before attempting to
catapult item through the node. This should make all
non-solid nodes diggable including loose leaves,
sedges, rushes, flowers, etc.
Mods that are responsible for inventory tabs can setup their
own event hooks, then call inventory_notify to alert inventory
tabs of certain events.
Inventory tabs can include registered handlers for specific events
allowing them to e.g. clear caches, and then if the handler
evaluates to true, the tab is updated.
Note that some tabs may have time-dependent contents (e.g. the
hints/challenges tab, or add-on mod tabs) and need to be notified
of this in the event that they are the current tab. It will
be the responsibility of each tab to watch for appropriate events
and perform background updates as necessary. The hint tab does
this on an event-driven basis from player discovery.
Items being "bumped up" upon landing due to the new column
preserving falling mechanics will never be lifted to higher than
the local maximum posiiton from which they fell.
This should prevent e.g. planks tunneling up several nodes from
a log chopping machine if there isn't enough room for the planks
to escape and the chopping machine is enclosed from above. Items
can still tunnel using the normal "settling" mechanics, but will
not have the strong upward bias that the column settling mechanic
gave them.
- 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.
Either dig them with a hatchet/adze, or "collapse"
them back to frames to move them by hand.
Even though it's the same basic material as the
wooden frame, having them too easy to dig
makes it to easy to accidentally dig while trying
to pull items from it.
When an ent settles, start an iterative process
of checking each ent near it for settling, bumping
ents upward as needed (during the process only)
and keeping them ordered by their starting height
so that things that start lower settle earlier (and
thus remain lower) even if ents have fallen and
bunched up together due to physics and large
timesteps.
Seems to work fully for falling_nodes (keeps
them in a column and settles them in order), and
partially for items (keeps them in a column but
does not always settle them in order).
