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.
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.
- Retire items_fall_thru group
- Add on_settle_item callback
- Open-topped storeboxes automatically capture
items settling on top of them
- Start converting form into storebox
- Future storebox recipe reform ingredient.
- Items fall through forms but players and
nodes (including falling_nodes) do not.
- Can be used to make e.g. special filter floors.
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).
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.
Based on what's being dug, rakes can have
different dig volumes and checks.
Lode rake now has 3 modes depending on
what's being dug:
- Loose things, same as wooden rake
- 3x3x3 exfoliating
- 3x1x1 soil tilling/digging
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.
It seems that when we access metadata too rapidly
it pulls data out of order or something, so that the
player damage time stuff is unstable, and healing can
start immediately, or more than 8 seconds later.
Caching this stuff manually seems to work around the
issue, and it seems that the metadata system is at
least EVENTUALLY consistent, so it's still good for
long-term use or across world unloads.
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.
