Internal Model

This page documents how mcfstd works internally. User datapacks should usually call public functions only.

Construction

Most public functions begin with:

function z_std:construct

Construction is guarded by _std_is_constructed in _reg, so normal calls skip setup after mcfstd has been initialized.

Core objectives:

Objective	Purpose
`_var`	User variables
`_reg`	Internal flags and registers
`_area_id`	Stable area trigger ids
`_area_player_id`	Stable area-trigger player ids
`_area_stale`	Area presence freshness
`_block_player_id`	Stable block-trigger player ids
`_block_context_ttl`	Placement context marker lifetime

Initial register state:

Score-holder	Objective	Initial value
`_std_is_constructed`	`_reg`	`1`
`_std_is_debug`	`_reg`	`0`
`_std_a`	`_reg`	`0`
`_std_x`	`_reg`	`0`
`_std_stdout`	`_reg`	`0`
`_std_area_next`	`_reg`	`0`
`_std_area_next_player`	`_reg`	`0`
`_std_block_next_player`	`_reg`	`0`

Registers

Register	Purpose
`_std_a` in `_reg`	Boolean result register
`_std_x` in `_reg`	Temporary integer operand register
`_std_stdout` in `_reg`	Legacy/output scratch value

Comparison functions and var:isset write to _std_a. stdout:true and stdout:false read _std_a.

Arithmetic and comparison helpers that need an integer literal often copy it into _std_x, then use scoreboard operation syntax against _std_x _reg.

Variables

Variables are fake score-holders in _var.

scoreboard players set <name> _var <value>

This keeps the implementation fast and simple, but it also means mcfstd cannot enumerate or pattern-match variable names from mcfunction code. Bulk removal needs an explicit list or a separate registry.

Internal counters such as _std_area_next, _std_area_next_player, and _std_block_next_player are stored in _reg.

Macro storage

The call: functions use storage z_std:macro.

Path	Purpose
`call_arg`	Single-argument call compound
`call_args.args`	Work queue for argument mappings
`call_args.out`	Generated argument compound passed to the target function

These values are temporary and are overwritten by later calls.

Area trigger internals

Area triggers use marker entities:

Marker tag	Purpose
`_std_area`	Registered area trigger
`_std_area_presence`	Player-inside-area state

The scheduled z_std:area/tick function scans the three vanilla dimensions. It reschedules itself only while at least one area marker exists.

Block trigger internals

Block triggers use marker entities:

Marker tag	Purpose
`_std_block`	Registered block trigger
`_std_block_stat`	Trigger backed by dynamic statistic objectives
`_std_block_global_place`	Any-block placement trigger
`_std_block_place_context`	Temporary detected placed-block context
`block`	Temporary public tag exposed during placement callbacks

Typed block triggers also create dynamic objectives named from the trigger key:

Pattern	Purpose
`_tbp_<k>`	Placement statistic objective
`_tbb_<k>`	Mining statistic objective

The scheduled z_std:block/tick function scans the three vanilla dimensions and reschedules itself while block triggers or placement context markers exist.

Load behavior

The datapack load tag runs:

{
  "values": [
    "z_std:area/load",
    "z_std:block/load"
  ]
}

These load functions reconstruct trigger support and restart scheduled scans for marker entities that survived reload.

Destruct

z_std:destruct marks the constructed state inactive and resets construction flags while leaving objectives in place. It is used by uninstall and can be used as a soft lifecycle reset.

Uninstall

z_std:uninstall clears scheduled trigger scans, removes debug and temporary player tags, removes dynamic trigger objectives, kills mcfstd marker entities in the three vanilla dimensions, clears macro storage, revokes the block placement advancement from loaded players, marks the datapack destructed, and removes static mcfstd objectives.

This is an internal function, but it is useful when removing the datapack from a world.