
PlayerTimer
This project adds a timer, which can be started by the player or by a commandblock. The timer is unique to the player and each player can have their own timer running. It is a server-side only installation for running minigames and timed challenges.
Links
Tags
Creators
Details
1.4.0
Compatibility
Changes
Changelog
All notable changes to PlayerTimer Fabric will be documented in this file.
1.4.0 - Minecraft 26.2
- Updated Fabric target to Minecraft 26.2
- Updated Fabric Loader requirement to 0.19.3 or newer
- Updated Fabric API dependency to 0.153.0+26.2
- Confirmed the Fabric module builds against the Minecraft 26.2 dependency set
26.1.x-1.2
- Timers are now persistent across server restarts and crashes
- Added admin commands (clear, clearall) gated behind op level 2
- Moved timer logic into
PlayerTimerdomain model - Replaced anemic setters with domain operations (start, pause, resume, stop, reset)
- Introduced
TimerOperationResultenum replacing exception-based control flow - Extracted
PlayerTimerCommandclass fromPlayerTimerMod - Added
TimerStorefor JSON persistence via Gson - Added periodic auto-save and save-on-state-change
- Consistent command source messaging via
TimerCommandContext - Player disconnect now removes timer from memory and triggers a save
26.1.x-1.1
- Added coloured timer support
- Added optional colour arguments to timer start commands
26.1.x-1.0
- Initial Fabric release
- Ported PlayerTimer from Paper to Fabric
- Added per-player timers
- Added countdown and countup modes
- Added timer state system
- Added visibility system
- Added Brigadier command support
- Added command block compatibility
- Added duration parsing with multiple formats
- Added action bar timer display
- Added countdown completion sounds
- Added Java 25 support
- Refactored timer logic into
PlayerTimerService
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:bWJidUw3:rXhAodtZ"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:bWJidUw3:rXhAodtZ"
}
