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.
This should provide a visual clue as to WHERE players
should put tinder to get it to catch properly, since this
seems to be a common problem players run into.
This should improve game efficiency/smoothness when
a lot of flammable stuff is present but there are no
corresponding massive fires.
This seems to address runtime jitter issues noticed
after placing hundreds of coal nodes inside a forest.
