Tags
Creators
Details
18.4.5-fabric-1.21.11
Compatibility
Required content
Changes
GriefPrevention3D v18.4.5
Wiki: https://github.com/castledking/GriefPrevention3D/wiki
Overview
With VisualizationGlow: true, players on clients older than 1.19.4 saw claim borders as blocks nudged out of
alignment, with an armor stand flickering into view as each one spawned. Those players now get the classic fake block
borders instead, while everyone else keeps the glowing ones.
Why it happened
Glowing visualization draws each border block as a block display entity, added in Minecraft 1.19.4. A server running ViaVersion accepts clients older than itself, so the server supporting display entities says nothing about what a given player can render. ViaBackwards translates a display into an armor stand wearing the block, which sits slightly off-centre — the nudged border, and the armor stand visible for the instant before it is dressed.
The visualization provider only checked the server's own version, so every player got the glowing treatment whether or not their client could draw it.
The fix
The provider now considers the viewer as well as the server. A client known to be older than 1.19.4 is shown the fake block visualization, which every version renders correctly.
Client versions are read from ViaVersion's API by reflection, so GriefPrevention3D gains no dependency and nothing changes on servers that do not run it:
- No ViaVersion installed: every client speaks the server's protocol, so nothing is gated. This is what already happened.
- ViaVersion installed: each viewer is checked as their border is drawn. Modern clients keep glowing borders; older ones get fake blocks.
- A player ViaVersion cannot identify: treated as speaking the server's protocol, the same as above.
Border displays were already spawned per-viewer, so an old client never saw another player's glowing borders either.
Also fixed
BoundaryVisualization decided whether a failed visualization belonged to GriefPrevention or to another plugin by
comparing providers by identity against its own singleton. Building a provider per viewer would have made every
internal failure report as coming from an "external visualization provider", so the check now tests the provider's
type, and the error fallback path builds a viewer-aware provider as well.
Upgrade notes
No configuration or storage changes. VisualizationGlow keeps its meaning: enable it and every client that can render
glowing borders gets them. Drop-in replacement for v18.4.4.
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:pqVXF7b5:ebBxDMl7"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:pqVXF7b5:ebBxDMl7"
}

