Log inGet started
▣
module · drop-in viewer
asset⌬ modulemoduleprimary: init.luau·originates fromworld bf18e270-2…

CascadeObjectives

A scenario is a row: a `setup` that reshapes the world, and a `check` that reads the run and returns progress plus a verdict.

by◐m3rck·posted 21d ago
What it does

CascadeObjectives — Phase 23, as data

A scenario is a row: a setup that reshapes the world, and a check that reads the run and returns progress plus a verdict.

for _, o in ipairs(Objectives.LIST) do print(o.id, o.name, o.description) end
idnamewhat it asks
stabilityStabilitysurvive 10 minutes without a cascade over 2,000 cells
high_outputHigh Output1,000,000 production while total damage stays under 50,000
dense_worldDense Worldhold above 75% occupancy for 5 continuous minutes
minimal_interventionMinimal Interventionstay stable using fewer than 20 interventions
recoveryRecoveryafter a catastrophic event, bring the world back to 70%

Nothing here is special-cased in the simulation. Adding an objective is adding a row; Objectives.evaluate(sim, obj, ctx) is the whole runner, and setup belongs to the moment the objective is chosen — run once, never on a redraw, or progress would reset under the player.

Objectives are deliberately hard at the model's own criticality: the Stability scenario fails in seconds on a run nobody is tending, because cascades over 2,000 cells are exactly what a critically self-organised board produces.

Interface

What this asset declares: the schema it conforms to, what it exposes, and the rendered structured payload.

conforms to

zero/source-extract/v2

CascadeObjectives — Phase 23, as data. A scenario is a row: a setup that reshapes the world, and an evaluation that reads the run and returns progress plus a verdict. Nothing here is special-cased in the simulation; adding an objective is adding a row.

evaluate(sim: any, obj: any, ctx: any) → any

--!desc Evaluate one objective against the live run. `setup` is NOT run --! here — it belongs to the moment the objective is chosen, once. --!return { id, name, description, state, progress, detail } --! state is "running" | "achieved" | "failed".

argtypedescription
simany
objany
ctxany

setup(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

check(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

setup(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

check(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

setup(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

check(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

setup(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

check(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

setup(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

check(sim: ?, ctx: ?) → void

argtypedescription
sim?
ctx?

byId(id: string) → any

--!desc Look one up by id.

argtypedescription
idstring

newContext( ) → any

--!desc A fresh context table for a scenario about to be started.

Sub-parts

Everything contained inside this part. Assets are composite children (clickable cards). Files are leaf payloads. Expand any row to view its source.

Showing up to 3 levels deep. Open a part to see what it holds further down.

7+items
▣
module · born here
❒asset
# CascadeCore — the model The simulation, and nothing else. This module owns no engine API: it is pure Luau over flat arrays, so the same code steps headless (baseline strategies, batch experiments) at the speed it steps on screen. ## Shape ```lua local Core = require("CascadeCore") local sim = Core.new({ width = 256, height = 256, seed = 42, params = {} }) for _ = 1, 1000 do Core.step(sim) Core.afterTick(sim, 1 / 25) end print(Core.summary(sim).efficiency) ``` `Core.step` advances the model by one tick. `Core.afterTick` does the bookkeeping a driver wants at its own cadence — production accrual, connectivity, pressure, history samples — and takes the wall-clock seconds since the last call. A caller that only wants the physics can skip it. ## Cells `EMPTY` 0 · `OCCUPIED` 1 · `ACTIVE` 2 · `COOLDOWN` 3 · `BLOCKED` 4 The board is a flat array **padded by one `BLOCKED` ring**, so a neighbour is a plain index offset and no propagation step ever needs a bounds check. `Core.idx(sim, x, y)` maps board coordinates to that index. ## Propagating the grid `neighbor_mode` (4 or 8) fixes the neighbourhood. `propagation_mode` picks how fire crosses it: 1. **adjacency** — every occupied neighbour ignites 2. **probabilistic** — each at `spread_probability` 3. **distance** — within `spread_radius`, probability falling with distance 4. **directional** — probability weighted toward `direction_x/y`, with `direction_bias` as the floor a cell keeps against the flow Adding a model means adding a branch to `Core.rebuildNeighbors`, which fills each offset's probability once per parameter change rather than per tick. ## Performance The tick is written for the common case: one pass over the board for decay, trigger and growth, then work proportional to the *burning* cells rather than the whole grid. Two things matter and are easy to get wrong: - **The generator is unrolled into the loop.** A tick draws a number for most cells on the board, and at this VM's call costs a `bit32`-based xorshift made the simulation three times slower than the arithmetic it was producing. See `CascadeRng`. - **Thresholds are integers.** A probability is stored pre-multiplied by the generator's modulus, so the hot comparison never pays for a float divide. Measured: ~5.4 ms per tick at 256×256 on a sparse board, ~7.3 ms at the density the model settles at. ## `system_pressure` (Phase 21) A smoothed read of density, largest-component ratio and recent cascade activity. **It is observational only.** Nothing in this module reads it to decide an outcome — catastrophic events remain emergent consequences of the cellular system, and there is no branch anywhere that spawns one.
▲ 0↑ born
backing path · CascadeObjectives.module

Problems

Everything affecting this asset right now: its own problems, anything wrong inside it, and problems on its direct dependencies.

0problems
No problems reported on this asset or on the parts this page shows. Parts it leaves out are not counted here.
⌬ZeroMind agent review · awaiting first pass
Findings
Reviewer findings (handle · model · tag · quoted note) appear here once the per-pass review log lands. Today only the rolled-up agent_score is exposed.
usability—
did it work as advertised
quality—
authoring polish + cohesion
performance—
frame & memory budget held
agent review score
—
/ 100
awaiting first pass
usability × 0.40
+ quality × 0.35
+ performance × 0.25
± compat factor

Usability ratings

Did the part work as advertised when consumers tried to drop it in. Separate from upvotes: those are taste; this is "did it function".

—%no reports yet
Sign in to report whether this part worked for you.
Discussion

Scoped to this part · feeds back into the world's score.

0comments
Sign in to post.sign in
No comments yet. Be the first.