Tags
Creators
Details
1.4.0
Compatibility
Changes
BetterPunish v1.4.0 - The Staff Desk Update
Punishments are rarely finished the moment they are issued. Reasons need correcting, durations change, and older cases need checking without digging through YAML files. Version 1.4.0 puts that work in one place.
New Features
Edit Existing Punishments
The new /punishedit <id> command opens an editor for an existing punishment. You can also make the change directly from chat:
/punishedit <id> reason <new reason>/punishedit <id> duration <duration>/punishedit <id> staff <staff>
Durations use the same format as the rest of BetterPunish, including 30m, 12h, 7d, 30d, and permanent. A changed duration is still measured from the punishment's original creation time. Duration changes only apply to bans, mutes, and shadowmutes.
Edits never replace the punishment or change its ID. BetterPunish keeps a local record of what changed, the old and new values, who made the change, and when it happened. The same information is also written to the console log.
Proofs still belong to /proof; the editor links back to that existing system instead of creating a second place for evidence.
A Proper Punishment Dashboard
/punishgui and /punishments now open a central dashboard rather than a single active-punishment list. From there, staff can browse:
- Active, recent, expired, and revoked punishments
- Bans, mutes, warns, and shadowmutes
- Punishment history for a searched player
Lists use player heads and keep the useful information short: type, reason, moderator, ID, date, expiration, and current status. Left-click opens the full record. Staff with betterpunish.edit can right-click to edit it.
Details Without Command Hopping
Every punishment now has its own details screen. It shows the complete record, proof count, and a short edit-history summary. From there, staff can open the player's history, list attached proofs, or move into the editor.
Active bans, mutes, and shadowmutes can also be removed from this screen. Removal always opens a confirmation menu first and checks betterpunish.unban or betterpunish.unmute again before doing anything.
Search, Filters, and Pages
Punishment lists are paginated and include clear back, previous-page, and next-page controls. Filters work with the punishment's real type and status rather than text from the item lore.
Player search uses a short chat prompt, so the player does not need to be online. Type cancel to leave the prompt. Unfinished search and edit prompts expire automatically; the default timeout is 60 seconds.
Expired temporary punishments are shown as EXPIRED as soon as their timestamp has passed, even when an older saved record was never explicitly updated. Revoked records stay REVOKED.
Permissions
The only new permission is:
betterpunish.edit– use/punisheditand edit records from the dashboard
Opening the dashboard still requires betterpunish.gui. Proofs, player history, unbans, and unmutes keep their existing permissions, and every sensitive button checks the relevant permission on its own.
Improvements and Fixes
- Tab completion for edit fields and common duration values
- Validation for unknown IDs, empty values, bad durations, and unsupported duration edits
- Asynchronous local saves and Supabase updates through the existing storage services
- Configurable dashboard titles, input prompts, timeout, cancellation text, and success messages
- Built-in defaults for servers updating without the new config keys
- New tests for editing, statuses, filters, pagination, and GUI permission checks
Configuration and Compatibility
There is no database migration for 1.4.0. Existing punishment IDs, proofs, local YAML files, and Supabase punishment rows remain compatible.
If you want to change how long chat input stays open, set gui.input-timeout-seconds in config.yml.
Summary
1.4.0 is about making existing punishment data easier to work with. Staff can find a record, inspect it, correct it, check its evidence, and safely remove an active sanction without leaving the dashboard.
Optional dependencies
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:61dNEC9e:5YkTi4OL"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:61dNEC9e:5YkTi4OL"
}

