SPaper starts from Paper and adds exactly the Gale and Pufferfish performance patches that hold up under scrutiny — nothing more. Every one is read against its real current diff, verified against a live 82-plugin production server, and rejected outright if it risks real gameplay behavior instead of a pure performance win. The result is a fork you can actually reason about: smaller, faster to keep current on new Minecraft versions, and never running a line of code nobody on the team has actually read.
Vanilla Paper is deliberately conservative — it fixes bugs and exposes plugin APIs, but it doesn't touch vanilla behavior for performance. The forks that do (Purpur, Pufferfish, Airplane, and others) solve that by applying hundreds of patches at once, which means running production on someone else's bundled judgment calls about which vanilla behaviors are safe to change, with no way to take just the ones that matter. Those large patch stacks are also notoriously slow to catch up after a new Minecraft release — resolving hundreds of patches against a fresh vanilla source can take other forks weeks or months.
Same world, the same real 82-plugin set, the same hardware — only the jar changed. A mixed 1,800-mob population (zombies, non-farmer villagers, skeletons, piglins — chosen to exercise the specific patches that touch each mob type) was calibrated to push vanilla Paper to roughly 30ms/tick, then held at an identical fixed population across 3 alternating trials per jar, sampling every 10 seconds for 5 minutes each trial.
Honest caveat: TPS itself didn't move (both jars held ~19.95) — at this specific load SPaper still has plenty of tick budget left, so this measures "same load, how much cheaper," not "how much more load SPaper can take before TPS drops" (a fair follow-up question, just a different test). The mob population was locked in place to isolate AI/tick cost from combat-driven population decay. Single-machine test; full methodology and raw per-trial numbers available on request.
Same setup, a different question: instead of holding load constant, each jar's mob population was independently calibrated — coarse jumps, then fine steps — to find the exact count where real /tps crosses below 19.5, confirmed with 3 fresh-template trials per jar (36 samples each, 10s intervals). Two real measurement bugs (an unreliable fast-search proxy, and boot-noise contaminating an early reading) were caught and fixed before they could produce false numbers — neither bad result is in the table below.
All 6 confirming trials were tightly self-consistent (vanilla: 18.0–18.4 TPS across 36 samples; SPaper: 18.9–19.4 across 36 samples) — not a single lucky run. Boot times were near-identical (72–73s both jars), so this is runtime capacity, not a startup artifact. Scope, stated plainly: this compares SPaper against vanilla Paper only — it says nothing about Purpur, Pufferfish, Airplane, or any other fork, and isn't an industry-wide claim.
Discipline cuts both ways. Alongside the 19 patches that landed, several real candidates were read in full and rejected outright once they turned out to risk actual gameplay behavior instead of a pure performance win — a stuck-entity retry timer, a movement early-return with a physics-correctness edge case, a fire-resistance visual change. Compatibility gets the same scrutiny: SPaper's own rebranded version string silently broke ItemsAdder's version-sniffing logic before it was caught and fixed — the kind of subtle plugin-ecosystem bug that's easy to miss on an empty test server and hard to miss when every change is verified against 82 real production plugins instead.
Purpur's Gradle patch-stack tooling is genuinely good — its scaffolding for applying, rebasing, and building a Paper-derived patch stack is what SPaper reuses. What got stripped out is every one of Purpur's own gameplay patches, so there's no upstream gameplay behavior to understand, fight, or accidentally inherit.
Milestone 2 hand-ported 19 specific patches from Gale and Pufferfish rather than merging either project wholesale — entity activation/AI throttling, line-of-sight and sensing caches, spawn-tick skips, and allocation-reduction wins. Every behavior change that ended up in SPaper was deliberately picked, read against its real current diff, and understood first.
./gradlew publishToMavenLocal installs spaper-api and spaper-server under the com.swag617.spaper group, so the rest of the plugin ecosystem can compile and test against SPaper directly, the same way it would against upstream Paper.
The default build output under spaper-api/build/libs and spaper-server/build/libs isn't directly runnable. A dedicated ./gradlew createMojmapBundlerJar task produces the actual server-ready jar, mirroring Paper's own multi-artifact build split.
Forked, rebranded, and confirmed to build with no gameplay or behavior changes of its own — byte-for-byte equivalent to vanilla Paper.
Hand-ported one patch at a time from Gale and Pufferfish, each read against its real current diff and verified with a clean compile plus a full boot against a real 82-plugin production set. Highlights: Dynamic Activation of Brain (throttles distant/idle mob AI ticking), a built-in /spaper health web dashboard, a pre-flight plugin compatibility checker, cached line-of-sight and climbing checks, a linked entity-tracker map, spawn-tick and explosion-resistance allocation skips, and shared block-destruction packets. 1.21.11 is frozen as the stable baseline for this line.
SPaper is maintained as parallel version branches, not a single moving line — every supported Minecraft version gets its own branch and its own full verification pass, so upgrading never means abandoning a working setup. The full 19-patch stack has been reconciled and verified against Minecraft 26.1.2: every conflict resolved against real current source, a clean standalone boot confirmed, and a full 82-plugin production test run passed cleanly. Future Minecraft versions get their own branch the same way.
The same reconciliation-and-verification process as Milestone 3, run again against 26.2: every patch checked against real current source, a standalone boot confirmed, and a full production plugin test. Not yet started.
Same process, next version in line. Not yet started.
There's no fixed patch-count target — new candidates get read and judged on the same bar as every one that's already landed, on every active branch. Also planned: an auto-update mechanism, and continued expansion of the /spaper health dashboard and compatibility tooling.
git clone https://github.com/swag617/SPaper.git && cd SPaper ./gradlew applyAllPatches ./gradlew createMojmapBundlerJar
Needs a real git clone — a downloaded zip won't build. A Java 21+ JDK is required; Gradle auto-provisions JDK 25 via toolchains if it isn't already installed. The first applyAllPatches run decompiles and remaps Minecraft, which takes a while — plain ./gradlew build compiles but does not produce a runnable server jar, so createMojmapBundlerJar is the step that actually does. See the README for full setup, first-boot expectations, and troubleshooting.