Tags
Creators
Details
1.1.0
Compatibility
Changes
MuseumWorld 1.1.0 is the first major stable update after the 1.0.0 release. This version brings the full 1.0.x development cycle into a cleaner, more complete and release-ready museum-world protection system, with stronger read-only protection, safer configuration handling, clearer blocked-action messages, new public version information, bStats metrics and a GitHub-based update checker.
Highlights
-
Added extended config-driven protection options
-
Added safe config validation and automatic cleanup
-
Added template-based config rewrite with preserved comments and key order
-
Added action-specific blocked messages
-
Added public
/museum versioncommand -
Added new and improved
/museum statusdiagnostics -
Added vehicle enter and vehicle damage protection
-
Added Elytra firework boost support while projectile blocking is enabled
-
Added official bStats metrics
-
Added GitHub Releases update checker
-
Improved Paper 26.1.2 compatibility handling
-
Improved README and configuration documentation
New protection options
MuseumWorld now includes additional protection toggles for common museum, showcase, lobby and read-only world use cases. New protections include item dropping and pickup, bucket use, fire use, TNT ignition, bed use, bone meal, portal creation, natural growth/spread/decay, projectile use, leads, name tags, item frame rotation, armor stand manipulation, hanging entities, vehicle placement/breaking and vehicle entering.
Strict config-driven protection
Read-only block and entity protection is now fully config-driven. MuseumWorld no longer relies on automatic read-only block/entity detection. Blocks and entities are protected only when they are explicitly listed in config.
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:6mJPAHKG:UhgwhiQw"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:6mJPAHKG:UhgwhiQw"
}

