The problem was pointed out by Josh
(gitlab.com/krazy-j) in merge request !22.
Apparently MT is not very smart about marking
mapblocks dirty to send to clients based on
calling mt.set_node(), i.e. it will mark them
dirty presumptively even if you set the node to
the same value it had already been.
This behavior can be confirmed by registering
an ABM against a common node like grass and
setting action = minetest.set_node. This
causes every mapblock containing that node
to be invalidated every interval, causing a big
spike in the packets received each interval
that you can clearly see on the F5 graph.
Rather than just fixing it for the most easily
observed case (fire checks), add utlity functions
to check this for ALL node change situations,
and apply it more or less universally anywhere
that we are not certain that the node is being
changed and we don't need to worry about the
extra overhead cost of the check.
Note that we don't need a
nodecore.set_loud_check call, as set_loud was
only ever being used already in cases where
we were pretty sure we were actually changing
a node.
- Smoke API uses expandable options param instead of positional
- Separate burst qty from automatically adjusted rate
- Backward compat with old API for now
- Standardize burst of smoke puffs for crafting
- Torches emit small smoke particles at increasing rate as they
start to wear out, to warn players holding them to light another
- Torches now emit a puff of smoke upon snuffing
During processing of the flammable ignition ABM,
nodes could ignite, causing the new ember nodes
created by this ignition to trigger fire propagation
instantly during the same tick by nodes still yet
to be processed for ABM checks during the same
scan. This often caused large areas of flammable
nodes, like wooden plank skyblocks, to be ignited
instantly in a specific direction from any source
ignition. This led to some "cheap shots" where
players were ruined by fire far more rapidly than
they should be.
Instead of processing flammability checks in
sync, delay them until the next tick, so that we
find all flammables to check before any new
igniters are created. This should tame fire
spreading back down to normal levels.
This was a workaround for a bug that it never actually really
addressed that caused stack fires to rage out of control. It
turned out the bug was a special case item duplication, and it
was actually fixed long ago.
Allow stacks of things to be burned for all their embers/ash
again, and also for more devastating shelf-fire disasters.
- New near_unloaded API that supports custom
distance parameter, map bounds check, and
some optimizations.
- Add area automatic unload check support to ABM
API and add to applicable ABMs, replacing many
old manual checks.
Note that the explicit unload check is only strictly
necessary when something will happen due to
a node NOT being present in the area, e.g. something
igniting due to absent coolant, or soaking quantity
being reset due to missing sources. In simple cases
where the absence of a thing causes the ABM to do
nothing, then the standard check can work because
the default action is to do nothing anyway.
Got through a bunch of mods, up next is optics.
- Try to use crafting recipes rather than resources as
the criteria for completing a hint.
- It's okay to use simple item observation for specific
cases of transient things like pliant concrete.
- It's also okay to still use simple observations for the
eligibility checks.
- Simple observation is also okay for naturally occuring
e.g. decay processes, like wilting flowers, as opposed
to crafts that need to be completed.
Make sparks bias "downward" for igniting nearby
materials, making starting a fire on top of thatch
more useful, and making thatch a more useful
tinder material.
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).
Standardize a "fair limiting" mechanism that
limits the items accepted into a queue, and
returns a uniform random sample when flushed.
Pass all cooking/curing smoke effects into fair
limit queue.
Apply fairl limit queue to fire sparks too.
Pliant concrete curing checks still seem to lag
the server somewhat, but at least now they
shouldn't hammer the client with particles and
kill framerate too.
- 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.
Before we were generating one spark spawner for
each ABM run, which could run hundreds of nodes for
a large blaze, and bunched them together. Instead,
push into a limited fair queue, and also spread the
actual spark spawning out across time to spread the
network traffic from fire.
We were using the igniter's position instead of the
flammable's to check if the flammable had already
been tested, which caused fire not to spread fully
though large blocks of contiguous flammables, and
biased the direction of fire spread where it did.
Thanks to Elon_Satoshi a.k.a. Copenhagen_Bram for
discovering, reporting, and helping to confirm that
this bug had a long history.
- Add debug logging
- Raise the ignition check limit to 250%
- Atomic ignition queue management, to ensure that
there's no chance of things getting "stuck" in the
blacklist due to partial queue resets
The use of hash instead of string for pos was causing
a bug in doors some time ago where doors would
randomly fail to fire ... and then now we're seeing
reports of fire that refuses to ignite for some specific
planks...
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.
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.
Don't reuse damage_per_second for damage on punch and radiant
damage. This allows these to be defined separately, i.e. no longer
assuming that all damage is from "heat" and can radiate. This
allows for things like thorny plants that hurt if you touch them
or stand in them but not if you stand near them.
Thanks to WintersKnight94 for reporting this.
- Storeboxes are now scalable.
- Standardize touch-hurt operation.
- Touch-hurt damage on scaling.
- Now possible to alter scaling time via scaling_time
group (percent of original scaling time)
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.
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.
