Links
Tags
Creators
Details
Licensed MIT
Published 2 years ago
Updated 3 days ago
All versions
2.1.0
Release
AutoStopper 2.1.02 months ago 35
Compatibility
Minecraft: Java Edition
26.2
26.1.x
1.21.x
1.20.x
1.19.x
1.18.x
1.17.x
1.16.x
1.15.x
1.14.x
1.13.x
1.12.x
1.11.x
1.10.x
1.9.x
1.8.x
1.7.x
Platform
Velocity
Changes
Added
- Added coordinator-owned operator lifecycle commands for mapped servers:
/autostopper start <server>,/autostopper stop <server>,/autostopper restart <server>,/autostopper hold <server>, and/autostopper release <server>. - Added command-specific permission nodes (
autostopper.command.start,autostopper.command.stop,autostopper.command.restart,autostopper.command.hold,autostopper.command.release) while retainingautostopper.adminas an explicit umbrella. - Implemented runtime shutdown holds that suppress automatic inactivity shutdown without blocking manual commands or player-driven wake-up. Holds survive unchanged reloads and clear on proxy restart, mapping removal, or mapping replacement.
- Manual stop and restart enforce strict safety invariants, refusing execution if connected players or lifecycle waiters are present, with an immediate deterministic pre-Docker safety re-check on the worker thread.
- Manual restart runs as one atomic coordinator-owned stop → start → readiness sequence under a single authoritative future.
- Surfaced hold state in
/autostopper statusand updated/autostopper helpwith permission-filtered entries and argument tab completion. - Pinned stable Velocity 4.0.0 build 6 as the production support line on Java 25, tested by the packaged-runtime system tests and the release-candidate Docker/Minecraft gate. Velocity 3.5.1 on Java 21 remains the tested minimum/floor, and Velocity 4.1.0-SNAPSHOT on Java 25 remains clearly labelled preview validation.
- Added the
RUNNING_UNVERIFIEDoperational state so a Docker-running container is not reported as ready until AutoStopper has completed the configured readiness contract for the current mapping lifecycle. - Connecting players now receive authoritative inspection, startup, readiness, connection, and terminal lifecycle messages. Late arrivals see the current shared stage and unique waiter count.
- Redesigned command and chat presentation around the brand identity ("Empty servers sleep. Players wake them."). Replaced legacy bracketed prefixes with clean brand prompts (
AutoStopper ›,AutoStopper ✓,AutoStopper !), added scannable deterministic status rows with humanized states and durations, and introduced permission-filtered help with fuzzy command matching. - Added contributor-facing message style guide (
docs/message-style-guide.md). - Added structured, typed lifecycle telemetry and bounded process-lifetime observability (#74). Authoritative
lifecycle operations emit machine-parsable
INFOlog lines (op=,server=,origin=,outcome=,elapsed_ms=,waiters=) with monotonic duration measurement, and intermediate stage durations emitDEBUGlogs. Simultaneous waiters receive 1 shared startup record plus individual connection wait records. Aggregates use thread-safe bounded memory with strictly zero PII and observational exception insulation.
Changed
- Operational status now reconciles Docker observations lazily with mapping-aware lifecycle revisions. Active transitions remain authoritative, stopped/degraded Docker state overrides stale quiescent state, and results captured before reload, mapping replacement, or newer lifecycle work are discarded without eager startup readiness probing.
Fixed
- Restored command and lifecycle messages on Velocity 3.5.1 by avoiding the Adventure 5 component-builder ABI incompatibility and validating every message factory against the pinned Velocity runtimes.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:PG4gqnzX:LhVOtc9C"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:PG4gqnzX:LhVOtc9C"
}

