Tags
Creators
Details
1.1-beta
Compatibility
Changes
Change
Permissions
This update added permissions. Players with OP permissions are granted all permissions by default.
Parent Permissions These permissions grant groups of child permissions.
viewinventory.see
Grants permission to view both a player's inventory and their ender chest. (Includes inventory.see and enderchest.see)
viewinventory.edit
Grants permission to edit both a player's inventory and their Ender Chest. (Includes inventory.edit and enderchest.edit)
Individual Permissions Use the following nodes to configure features individually.
viewinventory.see.inventory
Enables viewing another player's inventory using the /vi inventory <playername> command.
viewinventory.edit.inventory
Allows editing another player's inventory within the opened GUI. Without this, the inventory is read-only.
viewinventory.see.enderchest
Allows viewing another player's ender chest via the /vi enderchest <playername> command.
viewinventory.edit.enderchest
Allows editing another player's ender chest within the opened GUI. Without this permission, ender chests are read-only.
Disappearance bug
The item disappearance bug was primarily caused by two processes competing with each other.
1. The process of updating the GUI display (copying the target player's inventory to the GUI)
2. The process reflecting click actions (copying what the viewer clicked in the GUI to the target's inventory)
When clicking rapidly, process 1 would overwrite process 2. This caused the GUI to revert before changes were saved, resulting in items disappearing.
Solution
To eliminate this conflict, we fundamentally changed the approach.
Prioritize Click Operations
Valid click operations performed by the viewer within the GUI (such as item movement) are now handled by Bukkit's standard functionality. This ensures the exact same processing as Minecraft's normal inventory operations, preventing item disappearance.
Synchronize Changes Later
The modified GUI contents are now copied to the target player's inventory one tick after Bukkit completes the click operation. This completely eliminates processing conflicts and ensures changes are reflected safely.
Control Only Custom Slots
Plugin intervention is now limited solely to clicks on special slots like the trash can or glass panes. These operations cancel the event and are safely handled by the plugin.
This approach—“leave processing to Bukkit and reflect results later”—achieves both stability and a vanilla-like feel, eliminating the item disappearance bug.
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:FW4DNKUX:hqZ6wazf"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:FW4DNKUX:hqZ6wazf"
}

