nodecore-cd2025/mods/nc_api_active/init.lua

-- LUALOCALS < ---------------------------------------------------------
local include, minetest, nodecore
    = include, minetest, nodecore
-- LUALOCALS > ---------------------------------------------------------

nodecore.amcoremod()

nodecore.register_limited_abm = function(...)
	nodecore.log("warning", "deprecated register_limited_abm in "
		.. (minetest.get_current_modname() or "unknown mod"))
	return minetest.register_abm(...)
end

include("abmmux")
include("abmdelay")
include("abminvert")
include("abmarea")
include("stasis")
include("dnts")
include("aism")
include("soaking")
include("ambiance")
include("playerstep")
include("dynalight")
include("fluidwander")
Major rebuild of item_entity. 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. 2020-01-05 11:42:22 -05:00			`-- LUALOCALS < ---------------------------------------------------------`
Officially retire the ABM laundering hack Never saw any empirical evidence that this helped one bit. 2020-06-27 21:01:23 -04:00			`local include, minetest, nodecore`
			`= include, minetest, nodecore`
Major rebuild of item_entity. 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. 2020-01-05 11:42:22 -05:00			`-- LUALOCALS > ---------------------------------------------------------`

NC API dependency simplification. 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. 2020-01-05 12:59:12 -05:00			`nodecore.amcoremod()`

Deprecate register_limited_abm This has just been an alias to minetest.register_abm for a while now, and all ABM enhancement features have been added directly to the core API. 2021-07-10 11:09:44 -04:00			`nodecore.register_limited_abm = function(...)`
			`nodecore.log("warning", "deprecated register_limited_abm in "`
			`.. (minetest.get_current_modname() or "unknown mod"))`
			`return minetest.register_abm(...)`
			`end`
Officially retire the ABM laundering hack Never saw any empirical evidence that this helped one bit. 2020-06-27 21:01:23 -04:00
Experimental ABM Multiplexing Detect ABMs that share the same "signature" except for the central nodenames, and use a single ABM to run them, looking up the core bodies to run based on nodename on the Lua side. This could reduce the total number of ABMs we're using by almost half, and mitigate some of the performance issues that MT continues to have with ABMs. 2020-06-27 16:37:47 -04:00			`include("abmmux")`
ABM delay, prevent "prompt critical" ignition During processing of the flammable ignition ABM, nodes could ignite, causing the new ember nodes created by this ignition to trigger fire propagation instantly during the same tick by nodes still yet to be processed for ABM checks during the same scan. This often caused large areas of flammable nodes, like wooden plank skyblocks, to be ignited instantly in a specific direction from any source ignition. This led to some "cheap shots" where players were ruined by fire far more rapidly than they should be. Instead of processing flammability checks in sync, delay them until the next tick, so that we find all flammables to check before any new igniters are created. This should tame fire spreading back down to normal levels. 2022-01-22 16:20:10 -05:00			`include("abmdelay")`
ABM "inversion" API This is useful when we want to perform an action on a commonly-occuring node (like sand or item stacks) with a requirement of a neighbor of a less common node type (like igniters). Checking for B with A nearby can be a lot faster than A with B nearby if B is less common, so fewer neighbor checks actually need to happen. This was already done "manually" for the flammable/igniter interaction, but now this is a general API for all ABMs, that allows the inversion to be done nearly transparently with just a flag in the definition, and so the ABM rules can be written more simply, with the inversion handled elsewhere. TODO: Rewrite current manual-inversions, including the ones for flammable/igniter and lava/stone hardening/softening. 2021-03-21 12:08:08 -04:00			`include("abminvert")`
Begin standardization of unload bounds check - 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. 2021-12-18 11:28:14 -05:00			`include("abmarea")`
Add "stasis" option and command. This freezes many things that normally happen automatically in the world, including most ABMs and AISMs, and a few other custom step logic items like the player "hot potato" logic. This can be used for "creative mode" purposes to setup a complex build without it running itself away from you, and for texture pack authors, to have time to see things that are normally transient or difficult to observe because of the effects they have on nearby things or players. 2020-01-10 06:26:07 -05:00			`include("stasis")`
DNT API and reliable door ablation - New Delayed Node Trigger API that allows the use of multiple externally-defined node timer events, as long as on_timer of a node is not explicitly overridden. - Use the new DNT system to make door ablation reliable. 2020-06-18 22:35:47 -04:00			`include("dnts")`
Major rebuild of item_entity. 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. 2020-01-05 11:42:22 -05:00			`include("aism")`
			`include("soaking")`
			`include("ambiance")`
Finish base playerstep API Now all that's needed is converting existing mods for proof of concept. 2020-06-22 21:14:40 -04:00			`include("playerstep")`
Buff torch and scaling light sources. - Better compat with low gamma play. - Torch now emits some light when in inventory, even if not actively wielded. - Dynamic light API for mod use. 2020-02-22 21:57:08 -05:00			`include("dynalight")`
Unified fluid wandering system - New fluid wandering API, mostly unified logic, only needs some parameters, plus the "generation check". - More sophisticated behavior seeking down-slopes beyond simple immediate flowing node reach ("subtle slope" detection). - More reliable timing using DNTs. - Set firm movement rate of concrete, molten glass. - Reduce molten glass generations, since it can now be more reliably directed. 2021-08-02 07:17:51 -04:00			`include("fluidwander")`