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.
Apparently we will be required to enable
use_texture_alpha explicitly for anything using
any level of transparency, not just alpha
blending, in some future version.
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.
Instead of registering the TTL for a light and expecting
more time to be pushed in, use a fixed TTL of 0.25s and
register a callback to check if the light is still valid, i.e.
lights now pull time as necessary.
This should prevent light flickering that can happen
under heavy server lag, i.e. when the time step is
wider than the dynamic light TTL.
Lights that don't register a callback will be ephemeral,
and will disappear after 0.25 seconds, which can be
used to increase the chance that the server has had an
opportunity to move the light, as per torch destructor.
All possible light level nodes are pre-registered at startup time
so that light levels can be determined fully dynamically at run
time, without needing to explicitly declare what light levels will
actually be needed.
Hopefully this will make using dynamic lights a little easier
and lead to some interesting content.
Also reduce client packets by tracking dynalight node
ttl in-memory instead of meta. Lights might flicker out
a bit on area first loading, but some startup judder is
expected on any unloaded area anyway.
Add a "cheat" code for torch testing, and possibly for
other dev uses.
It seems there are a couple of scenarios in which MT
doesn't correctly run wield light timers to remove the
wield light; use an ABM to catch anything left over.
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.
Use high-res version in a few places we were using integer-res
timer before. This should e.g. smooth time variation of wind
strength for ambient sounds.
AISM's now tick against stacks, including in piles, shelves,
and player inventories, (hopefully) efficiently compared to
the old way with separate ABMs. Item entity support is also
possible, but not necessary yet.
This started out as a bugfix for being able to put a torch inside a
shelf, which didn't make much sense gameplay-wise. It ended up
going quite a bit further.
- Aggregate now gets wet in stack form. Swimming with dry
concrete now has consequences.
- Lux reactions, radiation, and infusion should now behave more
consistently.
- Sponges can now wet or dry in stack form, including inside
containers.
- Torch ignition, quenching, and extinguishing is now more
consistent regardless of context, and torches are now more
dangerous, and can ignite things in more contexts.
If a node is specially tagges with the stack_as_node group, and
the stack size is exactly 1, place as a real node instead of a
stack node.
This reinstates logic from WAY back in the super-early pre-alpha
days, except only for nodes explicitly tagged this way.
This should be applied only to nodes that aren't transformed in
any non-desirable way when placed as nodes instead of stacks, and
can be dug the same ways as stacks (i.e. snappy = 1 or
crumbly = 1).
Currently applied to sticks, staves, leaves, ladders/frames,
and torches. Ladder/frame placement offers some interesting
possibilities in terms of throwing ladders to rappel down holes.
Use the upstream coal textures from the fire mod, since that's
already a dependency, and we can make sure our textures are
consistent with the upstream ones. Make the burning torch tip
look embery and not just coaly.
