GeyserMC: Better Unsafe Enchantment Display For Bedrock
The Challenge of Unsafe Enchantments on Bedrock
For those of us running Minecraft servers, especially those bridging the gap between Java and Bedrock editions with projects like GeyserMC, we often encounter unique challenges. One such persistent niggle is how unsafe enchantments are displayed to Bedrock players. On the Java Edition, enchantments that go beyond their standard maximum level are typically denoted with Roman numerals, clearly indicating their enhanced power. For example, you'll see "Silk Touch II" or "Sharpness V." However, when Bedrock players connect through GeyserMC, this crucial visual cue often disappears. An enchantment like "Silk Touch II," which should clearly show its enhanced level, might just appear as "Silk Touch." While the enchantment's functionality remains intact thanks to Geyser's impressive translation capabilities, the lack of visual differentiation can be confusing and diminish the player's experience. This is particularly true when servers or plugins introduce custom enchantments or deliberately push existing ones beyond their vanilla limits to create unique gameplay mechanics.
Why Unsafe Enchantments Matter
The ability to display unsafe enchantments properly isn't just about aesthetics; it's about maintaining parity and providing a clear, intuitive experience for all players. Imagine a player spending significant time and resources to obtain a powerful, custom enchanted item, only for the Bedrock representation to look identical to a standard, low-level enchanted item. This disconnect can lead to frustration and a feeling that their achievements aren't fully recognized or understood. In the context of Spigot/Bukkit plugins, which are very common in the server community, unsafe enchantments are frequently used to signify special properties or boosted effects. Without proper display, these plugins lose a layer of their intended clarity and impact for Bedrock players. The core issue lies in how Bedrock's client interprets enchantment data. It seems to have a more rigid system for displaying enchantments, often truncating or ignoring Roman numerals beyond the standard maximums. GeyserMC does a commendable job of making the gameplay work, but the visual representation is where the current limitations are most apparent. This feature request aims to bridge that gap, ensuring that the power and uniqueness of these advanced enchantments are visually communicated to Bedrock players just as effectively as they are to Java players.
Exploring Potential Solutions for Unsafe Enchantment Display
When considering how to tackle the GeyserMC unsafe enchantment display problem, several avenues come to mind. One proposed solution involves leveraging Geyser's integrated resource pack system. The idea here is that the integrated pack could potentially raise the maximum level for all enchantments to a very high number, perhaps 255, or at least to the maximum number of Roman numerals that Bedrock can display. The actual, server-authoritative level of the enchantment would still be managed by the Java server. This way, the Bedrock client would see the Roman numerals, even if they represent a level far beyond the enchantment's intended practical limit. This approach aims to provide the visual feedback without altering the core functionality. Another thought revolves around the capabilities of Custom Mappings v2. It might be possible to use these mappings to detect specific unsafe enchantment levels and then apply custom lore to the item. For instance, if Silk Touch is enchanted beyond level 1, custom lore like "[II]" or a similar indicator could be appended to the item's description on Bedrock. This would provide a workaround for visual cues, though it requires more manual configuration for each specific enchantment and level combination. The ultimate goal is to ensure that Bedrock players can easily distinguish between standard enchantments and their more powerful, potentially
