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.
Hughes Ross has started to work on a PR for this
(https://github.com/minetest/minetest/pull/10140)
but it doesn't look like it will be ready until 5.4 at
least, and we will support pre-5.4 versions for
some time yet. The ability for TP artists to
override special_tiles is necessary to allow things
like flowing liquid textures to be customized in
texture packs.
Add a hack for these, similar to how we did the
inventory/wield image hacks.
Note that we are also forcing overrides for special
tiles, since there may be cases where we reuse a
base image without modifiers but TP artists may
still want an independent override.
Apparently this interacts badly with
optomechanics when multiple optic
tick cycles are running on a single
globalstep, since it may cause doors to
miss signals if they quiesce back to
off during the step.
Instead of limiting the number of cycles
to some arbitrary upper bound, run as
many cycles as necessary up to a CPU
time limit, i.e. we only allow expansion
of globalstep time by a fixed limit.
If we're running multiple optic ticks in
rapid succession, then we don't return
control to the rest of the game between
ticks, so there's no point in reading the
map more than once per pos, and no
point in updating the map until the end
when optics may have oscillated
across multiple states.
Maintain a cache and commit buffer
during each globalstep and only flush
them at the end.
Apparently as oilboi pointed out, node metadata
is kinda gross, and in this case we didn't actually
need it, since the information could actually
always have been inferred from the nodes
themselves.
Instead of storing output state in node meta,
just register a callback on the node definition to
interrogate the node itself about its power output.
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.
If the server can't handle optics, it would lead to a
runaway effect and bring the system down. Instead
only process up to half a second worth of optics on
each tick, so that this effect is capped and the server
will at least be able to chug along.
Optics keep track of path dependency info
used in calculating state. When a node is
added/removed in the path via the mod API
(i.e. not schematics, vmanip, etc.) then the
nodes whose state decisions depended on
paths going through there are automatically
triggered for a recheck.
This should make things like furnace sand
auto-loaders respond snappily.
Granted, memory use with this approach is
a concern, but we will just have to monitor it
under normal usage patterns.
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)
- Lenses no longer produce light from sun at all;
artificial light is always needed.
- Grass and trees survive, don't do dual-time check.
- Breeze sounds work in twilight.
- Sponge drying only requires twilight, now also can
happen under artificial light.
- Peat to grass happens under twilight.
Lenses work from sunlight up to roughly y = -10.
You can now have unlimited optic power from the sun,
but conducting it all the way down from the surface is
more of a pain than having a loop at depth.
- No day/night cycle, no sun/moon.
- Get rid of clouds too.
- Skybox is now 100% texture-packable.
- Natural light diminishes with depth.
Night-time no longer disrupts gameplay topside, but
skylights are no longer useful to an infinite depth and
artificial light is necessary for all deep mining.
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.
