Tags
Creators
Details
0.8.2
Compatibility
Changes
uxmEssentials 0.8.2
A bug-fix release for two faults in 0.8.1 that could stop a server dead, plus the new Custom Commands module and a per-world void rescue.
Requires Paper 26.2 on Java 25, same as 0.8.1.
Fixes
The PIN keypad no longer fights itself. On a server that requires a PIN, the create-a-PIN pad looped: the first entry went in fine, then the moment the pad asked for the PIN a second time it tore itself down and rebuilt faster than anyone could tap it, and the entered digits were wiped on every rebuild. Setting a PIN was impossible, and since the player is frozen until they have one, so was joining.
Two things were wrong. Showing a window over an open one makes the server close the open one first, so every pad the plugin put up while another was on screen arrived as a keypad close, and the listener that guards against a frozen player escaping read that as an escape and reopened. The guard meant to prevent exactly this was released before the open it guarded had actually landed, because opening a menu is asynchronous. The plugin now counts the opens it has asked for and not yet seen appear, so a close caused by its own open is told apart from a player walking away. The enrolment flow also no longer puts up a second pad at all: the submit button already clears the entry and redraws in place, so both entries happen at one window. A frozen player who closes the keypad still gets it straight back, exactly once.
A custom command no longer stops the plugin from enabling. A definition in commands/custom/ is keyed in the command catalog under a namespace, custom:<id>, and the catalog's identifier type refused the colon, so a single definition file was enough to fail onEnable outright. Namespaced identifiers are accepted now, and the generated commands.conf quotes such a key, since HOCON would otherwise read the colon as the separator between a key and its value.
Custom Commands
The 36th module, and a replacement for MyCommand. An operator declares a command in a file under commands/custom/ and the plugin registers it as a real command: typed arguments with tab completion, a usage line, and a place in commands.conf beside the built-in ones.
command {
name = "welcome"
aliases = ["hello"]
permission = "uxmessentials.customcommand.welcome"
console = true
cooldown = "5s"
cost = 0
}
arguments = [
{ name = "target", type = online-player }
]
actions = [
"message:<green>Welcome sent."
"delay:1s"
"broadcast:<gold>%player% <yellow>welcomes <gold>%arg_target%"
]
- The actions are the menu engine's own. Everything a menu button can do, a custom command can do, plus
delay:<duration>between steps. Nothing new to learn if you have written a menu. - Real arguments.
string,rest,int,double,bool,material,world,online-player,player, withminandmaxon the numeric ones, so an out-of-range value is a syntax error before a single action runs.%arg_<name>%and%args%expand inside the actions. - Real gates, in a fixed order: sender kind, permission, chain depth,
requirements, cooldown, warmup, cost. The cost is charged after the warmup completes, so a warmup a player walks out of costs nothing. - A one-line alias instead of an action list:
alias = "/gamemode creative"passes everything typed after your command straight through. - Written in game if you prefer.
/customcmd create <id>asks for the command word, the aliases, the permission, then each argument and each action, and shows you the finished file before it writes anything./customcmd list,info,test,reload,runanddeletecover the rest. - Privileged steps are opt-in and audited.
console:andcommand-as-op:are gated in the module's config, and a chain using a disabled one skips that step and says so rather than failing silently.
A bad definition never takes the others down: a file that fails to parse is skipped with a console warning naming it, and everything else still loads.
Worlds: void rescue
A player who falls out of a world no longer falls forever. Each world can name an ordered rescue chain (spawn, warp:<name>, at <world> <x> <y> <z>) and the height below which it fires, and the first step that resolves wins. It uses the involuntary-move path, so it leaves no /back point and plays no arrival effects.
Also
- The shipped teleport config now documents the
spawn { first-join / every-join / respawn / respawn-chain / exempt-permission }block that 0.8.1 introduced. - The build follows uxmLib to its renamed repository and its 0.5.0 line.
Downloads
| File | Where it goes |
|---|---|
uxmEssentials-0.8.2.jar |
Paper plugins/ (required) |
uxmEssentials-velocity-0.8.2.jar |
Velocity plugins/ |
uxmEssentials-redis-0.8.2.jar |
Paper plugins/ on each backend |
uxmEssentials-discord-0.8.2.jar |
Paper plugins/ |
uxmEssentials-rest-0.8.2.jar |
Paper plugins/ |
Upgrading from 0.8.1 is a drop-in: settings new in this version are appended to your existing config files under a header naming the version, and nothing you have edited is touched.
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:IpIrzRV9:bbkfpNHk"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:IpIrzRV9:bbkfpNHk"
}

