Links
Tags
Creators
Details
Licensed MIT
Published 2 years ago
Updated last month
All versions
2.0
Release
ExplosionProtector 2.0last year 52
Compatibility
Minecraft: Java Edition
1.20.x
Platforms
Paper
Purpur
Spigot
Required content
Any compatible version
Changes
Changelog
[2.0] – 2025-04-27
Added
- Guava-backed lookup cache (
Cache<String,Boolean> placementCache) to dramatically reduce repeated CoreProtect block lookups. - Localization support via
config.yml(language: <code>) and externalmessages_<lang>.ymlfiles for English, Russian, Spanish, Chinese, Hindi, Arabic, French, German, Japanese and Portuguese. - Automatic resource extraction of all
messages*.ymlfiles from the plugin JAR into the data folder on first run. /epcommand with three sub-commands:status/info— shows plugin status and number of blocks protected in the last explosion.language <code>— dynamically switch the plugin’s language at runtime without a server restart.
- Dynamic message loading (
loadLanguageMessages(lang)) to reload translated messages immediately after/ep languageis run.
Changed
- Explosion handling consolidated:
- TNT chain reactions now explicitly allow TNT to break through, while all other blocks placed by players remain protected.
- Unified logic for
EntityExplodeEventandBlockExplodeEventinto two succinct handlers.
- CoreProtect API check simplified to
APIVersion() >= 7(from>= 10) and proper plugin‐enabled test. - Logging and user feedback moved entirely into configurable message files instead of hard-coded strings in code.
- Comments and documentation updated to English throughout the codebase.
Fixed
- NPE safety: all CoreProtect lookups and message loads guard against
nulland absent resources. - TNT projectile: improved handling in
ProjectileHitEventto prevent lingering TNT entities from exploding unexpectedly.
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:wKqja9iv:xqzmFXiJ"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:wKqja9iv:xqzmFXiJ"
}

