All-addon development stand

This independent Gradle build composes the main Compukters development archive and every independent addon. It pins Minecraft 1.21.1 and NeoForge 21.1.252 with the following runtime:

Pinned Modrinth versions: Aeronautics 44pLdPGg, Propulsion H13U56dc, Cosmonautics HuCMavv8. Aeronautics 1.3.2 includes the upstream JEI compatibility fix; the older 1.3.1 bundle fails with recent JEI versions. The exact bundled Aeronautics mods and Sable libraries are extracted for the Loom dev classpath; no separate versions of Simulated/Offroad are selected. This stand has no distributable umbrella JAR. The main mod has no upstream physics dependency; the five Compukters addons remain independent. Compukters: Cosmonautics is an empty NeoForge scaffold for future integration. It exposes no Guest API or peripherals; its upstream JAR supplies both rocketnautics and dimensional_sable, which the runtime-set check verifies. Client and ordinary server runs include Cosmonautics. The GameTest composition excludes it and its empty addon: Cosmonautics requires its Deep Space dimension during server ticks, whereas vanilla GameTest worlds do not create that dimension. verifyGameTestPhysicsMods checks the original physics set and verifyGameTestClasspath ensures no Cosmonautics mod is included in that test runtime. Future Cosmonautics world tests require a server with its dimensions.

The boiler SCADA example uses Crafts & Additions liquid burners and the Connected kinetic battery.

For an interactive client from the repository root:

git submodule update --init --recursive
./gradlew stageAddonDevelopmentDependencies
cd addons/dev
./gradlew runClient

In IntelliJ, reload the linked addons/dev Gradle build and select its runClient task (or generated client run configuration). The game directory is addons/dev/run/client; extra manually installed mods belong in its mods subdirectory. The pinned mods above are already on the classpath and do not need copying there. Server and GameTest worlds use separate run/server and run/gameTestServer directories. Gradle rebuilds the main mod and all addon archives before launching, so editing them does not require a Maven Local publication.

Optional renderer mods are declared in addons/dev/gradle/client-mods.gradle.kts, with one dependency per mod. Comment out a dependency line and reload Gradle to disable it, or comment out the script’s apply(from = ...) line in addons/dev/build.gradle.kts to disable the whole group. Voxy requires Connector, Forgified Fabric API and Sodium; disable Voxy before removing any of those dependencies. The script pins Connector 2.0.0-beta.17, Forgified Fabric API 0.116.15+2.3.5, Sodium 0.8.13, and the realBritakee/voxy-neoforge 0.2.15 fork for Minecraft 1.21.1. Gradle downloads them from Sinytra Maven, Modrinth Maven and the fork’s GitHub Release. Do not also copy these JARs into run/client/mods. Voxy Worldgen 2.4.2 (NeoForge 1.21.1), Cloth Config 15.0.140 and Better ModList 21.1.4 are also pinned there as separate Modrinth dependencies. Cloth Config and Better ModList provide access to its generation settings through the mod configuration screen.

Connector and Sodium contain early ModLauncher services and use forgeRuntimeLibrary. Forgified Fabric API uses modRuntimeOnly with its Maven dependencies, so Loom remaps every API module into the development namespace. A standalone API JAR copied into mods retains production lambda names and can fail to apply its mixins; declaring only that local umbrella JAR also omits its nested API modules after Loom’s remapping. Voxy uses runtimeOnly, keeping its Fabric intermediary names for Connector. Its NeoForge filename does not mean that it is a native NeoForge mod. The run configurations also supply connector.clean.path from Loom’s unpatched Mojang-mapped Minecraft provider; this is separate from the patched development Minecraft JAR. These dependencies belong only to the development stand and are not packaged into Compukters or addon releases.

Configuration Cache and parallel execution are enabled in this stand itself, so independent built-in program generators can run concurrently inside the included Compukters build. Repeated commands reuse the configured graph; --max-workers=N limits concurrent work. After changing the addon Gradle plugin, rerun stageAddonDevelopmentDependencies in the same workspace used by this stand before launching: the plugin is resolved from build/addon-sdk, not compiled by the launch graph. The stand uses Loom directly; it has no Architectury Plugin transformer or platform-common source set.

Temporary flight diagnostics currently keep a 3x3 area of chunks ticking around each loaded computer. For Sable constructions the area follows the transformed world position of the computer, rather than its virtual storage coordinates. Tickets refresh every ten ticks, expire after forty ticks, and are released when the computer disappears, the server stops, or /compuktersdev forcechunks off is run. /compuktersdev forcechunks on enables them again; these commands require operator permission. No vanilla force-load flags are saved to the world. This aid belongs only to the development stand and starts disabled in GameTest runs.

Run these verification/development commands from addons/dev with Gradle on JDK 25 and a Java 21 toolchain available:

./gradlew-sandbox-dev-parallel-summary verifyAddons
./gradlew-sandbox-dev-parallel runGameTestServer
./gradlew-sandbox-dev-parallel runClient
./gradlew-sandbox-dev-parallel runServer

verifyAddons checks all standalone addons, verifies that their development archives contain only their own implementation, and checks the complete pinned physics mod set through verifyPhysicsMods plus the separate GameTest runtime. Every client/server launch performs the full physics-set check; GameTest launches check their separate runtime set. The common GameTest server loads complete test archives instead of the ordinary addon archives, registering the Create, Sable, Propulsion and development lifecycle scenarios together. Client and ordinary server runs load the ordinary archives. Each archive is built by its owning included Gradle build. The empty Cosmonautics addon loads only in ordinary client/server runs and adds no GameTest scenarios. Addon Guest bundles use the current workspace SDK tooling and platform bundle, so launches do not mix a stale published compiler with the base mod from this checkout.

To add another independent addon, include its build in settings.gradle.kts, add its stable development archive to the map in build.gradle.kts, and declare its upstream runtime dependencies here. Add a GameTest archive only when its upstream mods support the test server’s world setup. The addon keeps its own standalone checks, test registration and metadata. The shared stand owns only launch and verification composition.

Compukters exposes the Create Guest API, request-only sable.physics.Physics.snapshot() and the independent propulsion.thrusters.CreativeThruster.named(name) and CreativeVectorThruster.named(name) control APIs. Select the required addon IDs in each Guest project’s compukter.toml. See the Sable guide and Propulsion guide for examples, units and control lifetime.

Joint verification on 2026-10-11 with Sable 2.0.6 passed all 27 required GameTest scenarios and the standalone Create and Propulsion check tasks. The fixtures use configurator-bound peripheral networks and exact device identities. Construction unload/reload restoration has also been checked manually. Free-flight PID stability still depends on the construction and controller tuning. Propulsion 1.1.5 emits missing-model warnings (including oxidizer states and lodestone tracker overlay) from its upstream resources; these do not prevent startup.

The stand also registers three hibernation lifecycle characterization tests (issue #697). They run with the actual pinned Create/Sable/physics mods and the development chunk loader disabled:

• An ordinary computer’s remote chunk unloads while two computers 64 blocks apart on a force-loaded Sable construction retain their runtime epochs and execute shell commands. Sable’s internal plot chunks are distinct from the external world chunks; construction force-load tickets can keep external chunks available without vanilla force-load flags.
• Controlled construction serialization/reload exposes a valid physics body before either computer has an actor. Real physics substeps are counted before actor attachment and shell readiness. The test then removes the construction ticket and observes natural Sable unload/reload through its holding-chunk manager. A fixed joint holds the test body in place during asynchronous startup; the physics system is not globally paused. This joint is a fixture restraint, not a proposed restoration barrier.
• A Create bearing captures computer NBT but has no computer movement actor. A separate railway fixture advances five blocks through the real global railway manager with no loaded carriage entity and with Sable installed. It constructs a straight graph and serialized carriage directly; it does not prove station assembly, schedules, portals or trains running on tracks inside a moving Sable plot.

The stand also runs Sable hibernation tests that retain execution and query the same construction after reload with live physics, for both one and two computers. Propulsion hibernation tests retain ordinary/vector engine commands across computer replacement, construction reload and world filesystem store restart. They also cover stale handles for replaced engines and rollback when another controller owns an engine.

Computers resume saved execution after construction reload; physics continues during restoration without a readiness barrier. Propulsion rebinds owned commands before Guest execution continues, but thrust may lapse while unloaded or restoring. Failed capture or restoration falls back to a fresh boot with identity and /home retained. Active Create resources still do not support capture. check compiles the stand’s GameTests; runGameTestServer executes them.