Aurora Engine

Aurora is the execution model, not a plugin and not a config flag. It defines which thread may mutate which state, how region work is selected, what happens when a caller crosses a boundary, and how the runtime reports the result.

Why region threading

A single server tick serializes every world’s work. Aurora groups world state into regions and gives each region an owner thread, so independent regions can make progress without sharing one global mutation point. The gain is not automatic: it depends on the world’s topology, the plugins, and how often work crosses a region boundary. SourbyCraft makes no blanket performance claim.

Execution model

Global lifecycle

Bootstrap, configuration, world admission, and the server lifecycle run before region threads take ownership. A region does not begin ticking with a half-started world.

Region ownership

A region is a set of chunks with one owner thread. Chunks, entities, and block state in that region are mutated by the owner. The runtime refuses a write from a thread that does not own the region instead of allowing a race. Ownership is a correctness rule, not a convention.

Scheduling

Aurora schedules region work by deadline (EDF). A region runs because the scheduler selected it, not because a caller happened to be nearby or because a global loop reached it. The scheduler is also where missed deadlines become observable.

Observability is part of the model

The same metrics runtime feeds /tps, /mspt, /perf, HUD bars, /aurora, and Spark. There is no second, friendlier number for the command output. See Observability.

Scheduler and deadlines

Each region carries a deadline for its next tick. The scheduler picks eligible work in deadline order and records lateness when a region overruns. A slow region is a first-class signal; it is not averaged into a global tick that looks healthy.

Cross-region boundary

Work that touches another region has an explicit path. It can be scheduled, bridged, or refused depending on the API and the caller. It never becomes an implicit mutation on the caller’s thread. The bridge for non-region-aware plugins is opt-in and is still being qualified; it is not the core runtime’s definition of correctness.

• Region-aware API calls route through the scheduler or an explicit cross-region operation.
• Legacy synchronous paths are bounded and recorded; they are not allowed to hang shutdown.
• The Paper API is available under dev.iyanz.sourbycraft.api; the Canvas API is removed.

Shutdown

Build 48.4 tightens the shutdown seam. A synchronous chunk load requested from the region shutdown thread is refused up front with an owned message. The scheduler halts before plugins disable, so a load scheduled from a plugin’s onDisable cannot run after the region stops. An already loaded chunk still serves the write. This is a correctness fix, not a performance change.

Limits and current status

• The current release is not STABLE; Build 49 is the stability gate.
• The compatibility bridge is off by default and still under qualification.
• Region threading changes plugin timing. Code written for a single main thread may need changes.
• SourbyMods is a native loader for this runtime. It is not Fabric or Forge compatibility.
• No benchmark, player-count, or “faster than Paper” claim is made on this site.