RTLoadLib

Standalone load-lifecycle library with no external dependencies. 4 functions, each gated by its own score guard. Single pack, no overlays.

Real limitations — read before use

There is NO ordering guarantee. The pre_load → load → post_load → start sequence is not enforced by this pack. None of the four functions are bound to minecraft:load — only the function that sets default score values (internal/set_defaults) runs automatically. The four functions themselves are called entirely MANUALLY; the calling pack (RTWrapper/ dataLib) decides the call order in its own code. RTLoadLib cannot enforce this because Minecraft gives no mechanism for one pack to control another pack's call order.

What "pre_load is for checks" means: RTLoadLib does not decide WHAT gets checked inside pre_load. It only provides a guarded checkpoint skeleton — "there is a check stage here." A consumer like dataLib writes its own check logic (is a player present, is there a macro./ame. storage footprint, etc.) in its own function, then calls function rt_loadlib:pre_load.

Default state: all ACTIVE (1). internal/set_defaults runs automatically via minecraft:load and sets the 4 scores to 1 — but ONLY if they have never been defined. If someone manually sets one to 0 (disabling it), that 0 is PRESERVED across subsequent /reloads and is not forced back to 1. This behavior relies on distinguishing "undefined" from "0" via a full 32-bit range match (matches -2147483648..2147483647) — whether this test actually makes that distinction correctly in Java Edition has NOT been verified by testing, only inferred logically. Confirm this yourself via /reload.

max_format: 999 is not a real version number. As noted previously, this is a workaround — if a real syntax-breaking change happens in the future, the pack may silently misbehave with no incompatibility warning.

Scores (objective names are case-sensitive)

Objective	Function	Guard behavior
RTLoadLib.preLoad	rt_loadlib:pre_load	return fail unless 1
RTLoadLib.load	rt_loadlib:load	return fail unless 1
RTLoadLib.postLoad	rt_loadlib:post_load	return fail unless 1
RTLoadLib.start	rt_loadlib:start	return fail unless 1

All are held on the $rtloadlib fake-player holder (tied to the pack's global state, not a real player — $ cannot appear in a real player name, so there's no collision risk).

rt_loadlib.ver (lowercase, a separate objective) is set inside rt_loadlib:load — RTLoadLib's own internal version flag, a distinct signal external packs can check to confirm RTLoadLib actually ran.

Usage (from RTWrapper/dataLib)

# in your own load function, in whatever order you choose:
function rt_loadlib:pre_load
function rt_loadlib:load
function rt_loadlib:post_load
function rt_loadlib:start

To temporarily disable a stage:

scoreboard players set $rtloadlib RTLoadLib.preLoad 0

Dependencies

None. RTLoadLib does not require any external pack, and does not trigger any external pack's code on its own.

dataLib-specific logic does NOT belong here

Dialog-vs-say selection when a player is present, macro./ame. storage detection, and a macroEngine→dataLib migration wizard belong OUTSIDE this pack, in dataLib's own code. RTLoadLib does not — and should not — contain this: a library should not carry its consumer's business logic.

Not tested

Never run on an actual Minecraft client/server. Syntax was verified against official sources but no /reload test was performed. In particular, the "undefined vs 0" distinction inside internal/set_defaults needs verification.