Links
Tags
Creators
Details
1.0.14
Compatibility
Changes
Lands support
Land owners can now decide who may use Enigma Storage on their claim — the most requested integration after WorldGuard.
- New role flag
enigma_storage_use— toggle it per role (visitor / member / your own custom roles) right in the Lands flag menu. No commands to learn. Enabled by default, so updating does not lock anyone out of storages that already exist. - Falls back to
INTERACT_CONTAINERif the flag is unavailable. Storage contents are treated like a chest, not like a button. - Placing and breaking use separate flags (
BLOCK_PLACE/BLOCK_BREAK), so roles that may build but not break behave the way you configured them. - Hoppers are checked against the rack owner's role — your own automation keeps working inside your claim, while outsiders can't pipe items out of your storage from outside it.
- Soft-dependency — if Lands isn't installed, nothing changes and no errors appear.
- Works alongside WorldGuard: when both are installed an action needs approval from both, so enabling Lands can never weaken an existing WorldGuard setup.
Security fixes — changing the server language could hand over your storage
The rack owner's UUID was stored in NBT, but every read of it was gated behind a lore line
rendered in the current language. After switching language:, that line stopped matching
and the owner was reported as "unknown" even though the UUID was still there. Three results,
all fixed:
- A rack could be taken over by the next person who opened it — the plugin decided the rack was brand new and reassigned ownership.
- The owner's UUID could be erased permanently — the DSU Lock is rebuilt on every IO GUI open and re-wrote the owner as an empty value.
- Owners lost access to their own locked racks and could no longer change their settings.
These are independent of Lands and affect any server that has ever changed its language. Updating is recommended for everyone.
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:W47kt40y:omsSUVQ8"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:W47kt40y:omsSUVQ8"
}

