Tags
Creators
Details
2.5.1
Compatibility
Required content
Changes
Summary
WorldEditDisplay 2.5.1 is a patch release that restores reliable WorldEditCUI client detection and handoff while making player display settings and renderer refresh commands apply consistently.
Players without WorldEditCUI continue to use the built-in server renderer. Players with the client mod are now detected from the official version handshake and receive native CUI packets without duplicate server-side selection displays.
WorldEditCUI Compatibility
- Detects the official direct
worldedit:cuiversion handshake (v|4and future protocol versions) - Retains compatibility with legacy
minecraft:registerchannel announcements - Parses REGISTER payloads as exact NUL-separated channel names instead of substring matches
- Restores native WorldEditCUI priority even when server rendering is auto-enabled
- Keeps Bedrock/Floodgate clients on the server renderer
Renderer Handoff & Reliability
- Cancels pending server render work when a native CUI client is detected
- Clears selection display entities that were created before the client handshake arrived
- Prevents toggle, settings reload, and renderer refresh operations from recreating duplicate server displays for native CUI users
- Keeps CUI and Bedrock routing state visible across packet and scheduler threads
Player Settings & Command Fixes
- Makes whole-renderer resets clear cached player overrides correctly
- Makes
/wedisplay reloadplayerdiscard pending in-memory edits before reloading saved settings - Exposes and persists the missing
max_grid_spacingandsqrt_scale_factorplayer settings - Supports
-1as unlimited maximum grid spacing - Refreshes active selections immediately after enabling rendering or reloading server configuration
- Rejects unknown
/wedisplay viewsubcommands instead of unexpectedly toggling view-all mode - Loads the bundled Simplified Chinese (
zh_cn) language resources - Corrects the grid-division command example to use a value within the default player limits
Testing & Build Updates
- Added unit coverage for direct CUI handshakes, legacy REGISTER lists, exact channel matching, native-client routing, and Bedrock fallback
- Extended the Paper/Mineflayer end-to-end test with normal and CUI-capable clients
- Verifies that silent server handshake injection does not falsely detect normal clients
- Verifies native client detection, existing entity cleanup, outbound CUI forwarding, and renderer refresh suppression
- All 47 unit tests pass, and the Paper 1.21.11 end-to-end workflow passes with PacketEvents 2.13.0
System Requirements
| Component | Requirement |
|---|---|
| Minecraft / Platform | Paper / Folia / Spigot (Spigot Version) 1.19.4 ~ 26.2, where builds are available |
| Java | 17+ |
| PacketEvents | 2.13.0+ |
| WorldEdit | Latest stable / FAWE |
| ViaVersion | Optional, used for particle fallback auto-detection |
| Floodgate | Optional, used for Bedrock player detection |
Upgrade Notes
- No breaking configuration changes from 2.5.0
- Existing player settings and accepted share relationships remain compatible
- Native WorldEditCUI users no longer need to disable the server renderer manually
- Update PacketEvents to 2.13.0 or newer before upgrading
- A full server restart is recommended after replacing the plugin JAR
- No client-side mod is required for the built-in renderer
Download
The Paper-compatible plugin JAR is attached to this release. The same artifact supports Paper and Folia; use the Spigot build profile when producing a dedicated Spigot artifact from source.
Support
For issues, feature requests, or questions, please open an issue on the GitHub repository.
Full Changelog: 2.5.0...2.5.1
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:eVvfozdY:eCdfNq1F"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:eVvfozdY:eCdfNq1F"
}

