Create Aeronautics: Freeze Staff

The problem

Every loaded Simulated contraption costs server tick time whether or not it is doing anything.

A sub-level is stepped by the physics pipeline several times per game tick, its actors are advanced on every substep, and every block entity inside it is ticked by the server exactly as if it were part of the world — because it is. A parked airship, a docked barge, a stack of freight crates and a half-finished build in the corner of the base all keep paying that cost, permanently, at full rate.

This scales linearly. Ten contraptions cost ten times one. On a world built around Create Aeronautics, the contraptions that are actively in use are usually a small fraction of the contraptions that exist, and the rest quietly consume the tick budget until TPS starts falling.

What this mod does

Create Aeronautics Freeze Staff adds one tool that takes a contraption out of the simulation entirely while leaving it standing exactly where it is.

A frozen contraption keeps its blocks, its position and its appearance. What it stops having is a per-tick cost.

What freezing removes

For a frozen contraption, the following work is suppressed at its source:

Rates assume the default of four physics substeps per game tick.

The rigid body itself is pinned by a fixed constraint and allowed to sleep, so it is no longer being solved or moved. Its network position stays intact, so clients continue to see it correctly.

Block entity ticking is intercepted on three separate paths, because Sable sub-level chunks live in the parent world and are reached by vanilla chunk iteration as well as by the sub-level pipeline. Suppressing only the physics phase would leave most of the cost in place.

Freezing is not destructive

A frozen contraption is paused, not disassembled or unloaded.

Scheduled block and fluid ticks that were suppressed while frozen are recorded and replayed on release: the affected blocks are rescheduled and their neighbours forced to re-evaluate, so redstone signal strength and fluid flow resume consistently instead of latching in a stale state.

The freeze is recorded against the contraption's own identity rather than its position, so it survives chunk unloads, world reloads and server restarts. On reload, a frozen contraption is restored to the exact pose it was frozen at — it does not drift, settle or slide out of alignment while nobody is watching.

While frozen, its blocks cannot be broken, placed into or interacted with. Blocked attempts report the reason on the action bar rather than failing silently.

Usage

Connected freezing

Freezing propagates along two independent relations, both enabled by default and both configurable:

• Contact — contraptions whose bounds touch the frozen one, within a configurable tolerance.
• Ropes — contraptions attached to the same rope.

Propagation is transitive. Freezing the lowest crate in a stack freezes the entire stack; freezing one end of a rope chain freezes the chain. This matters for performance as much as for physics: a docked assembly is usually the unit you want to park, and freezing it one piece at a time would leave most of its cost behind.

Releasing works the same way and is confined to contraptions that are actually frozen, so it cannot reach past the group into unrelated structures. Sneaking suppresses propagation in both directions for a single interaction.

Configuration

config/freeze_staff-common.toml

Commands

Both require permission level 2.