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.
If there's any coolant near a node, that blocks
all application of heat and prevents it from being
cooked, and also prevents any passive slow-cooling
recipes from operating on it (i.e. racing against
the quenched recipes).
Use coolant neargroups for quench check too,
for consistency. Add memoization to the recipe
data on the check, so to avoid doing the quench
scan for each recipe separately.
If you have enough glowing prills in a stack, then
making a lode cube always takes precedence over
"stone anvil" hot-forging recipes. If players want to
make toolheads they'll just have to make sure they
don't have excess amounts of lode in the stack; it's
a good reason to eventually switch to cold-forging
on tempered anvils anyway.
Finally use the new Forms to craft shelves
using a 2-component recipe, and replace the
old 3x3 recipes. This affects:
- Wood shelves
- Clear glass cases
- Float glass cases
- Lode crates
- Tote handles
For now, we're just going with the simplest
recipe of just putting an item into the form.
If players want to store things in the form
without assembling a shelf, they'll have to
remember to drop items in through the top
only.
Forms may have served a purpose as makeshift
storage when actual shelves are too expensive
but this is NOT their purpose. They are
primarily intended as crafting ingredients for
proper storage, and secondarily as hoppers for
stack-fed machines. Any ability to use them as
actual player-controlled storage devices is
purely coincidental and not guaranteed.
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.
- 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.
Instead of registering 12 separate recipes for
each anvil recipe, just register 2: one for each
temper, and do a second lookup for anvil types
in pre/post check. This should avoid having
to re-evaluate all the rest of the stuff for each
anvil/temper combination type.
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.
- 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.
Instead of draining only into air/non-walkable below, allow
draining into any space air can pass, including ones where the
prills would be immediately displaced, e.g. into a frame.
This also allows it to drain directly into an existing stack of
glowing prills without an intervening airspace. This should tone
down the difficulty of figuring out ore smelting a bit, and
make for somewhat more interesting lode furnace builds.
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).
Lock more things behind prerequisite hints, even if
they're not absolutely strictly necessary to complete
in that order, if they would commonly be done in
that order. This reduces players being overwhelmed
by available hints very early in the game, and avoids
red herrings like "find lux" which can technically be
accomplished but yields no useful results until the
player can act on them.
- 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.
The original theory was that preallocating the array forced lua
to use the "array part" of a table instead of the "hash part",
which should be faster since lookups are a simple linear offset
calculation and not a hash with collision check.
It turns out, however, that in empirical testing, whether the
array-preallocated or the naive-allocated version is faster depends
on circumstances, such as how sparse the array is, how uniform
access is, or how much other load the system is under. This seems
to suggest that arrays are more computationally-efficient but less
cache-efficient, so cache evictions caused by other concurrent
processes may slow this method down significantly.
Worst-case performance will be the most noticeable here, since a
system that's heavily loaded would have the most need for speed
in the first place, so it's probably better generally to use the
naive allocation.
In all, the naive allocation method also seemed to be the least
sensitive to external factors. In addition to the array method,
attempts to pre-compile the dynamic checks into a binary tree of
if/then statements (which could be JITted and optimized) failed
as well.
For one thing, it's a bit overpowered when you go
right from infused still digging lode ore as loose
cobble, right to boosted-infused digging it as raw
ore.
For another, uncobbled lux stone is purposefully
labeled as just plain stone to force the player to
pay attention to light cues, but this would make
inventory management problematic once smooth
lux stone has been collected with boosted tools.
This reverts commit 253c2282917ecade5b8356d592edab40b1d517f5.
Apparently this warning is full of crap. Explicitly
setting use_texture_alpha in the node def does
something DIFFERENT than what the engine says
it's doing enabling it internally. use_texture_alpha
enables alpha BLENDING, which is what we
don't want with interpolation filters, whereas
leaving it off enables alpha THRESHOLDING which
is exactly what we want.
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.
