Tags
Creators
Details
1.1.0-mc1.20.6
Compatibility
Changes
1. Overview
- KIB now automatically removes items dropped from fragile blocks when they are broken.
- PacketEvents is now supported to improve client-side rendering when restoring fragile blocks. It is optional but highly recommended.
- Added
bamboosas fragile blocks (BAMBOOandBAMBOO_SAPLING). - Updated the
coralsfragile block category to add all implementations ofCoralWallFan. - Added bStats for plugin metrics.
2. Auto-removal of items dropped from fragile blocks
When fragile blocks are broken, KIB automatically removes items dropped from them. Note that they may be visible for a few milliseconds before being removed, as one server tick is required to detect them.
However, if you are using PacketEvents, they are not visible at all, as the packets related to fragile block item drops are canceled.
3. PacketEvents support
If the PacketEvents plugin is detected on the server, it will be used to cancel certain packets events in order to improve client-side visuals and performance. PacketEvents is optional but highly recommended for a smoother experience.
For any fragile block that is restored, KIB uses PacketEvents to:
- Hide break particles.
- Cancel break sounds.
- Hide block item drops (they are automatically deleted by KIB anyway).
- Cancel break animation.
Note that the break animation is not canceled for doors. Interacting with a door would otherwise cause it to appear half-open if the corresponding packet event was canceled. This is also why fragile doors may flicker.
β οΈ Please also note that this may not always be flawless. The client appears to anticipate some packets from the server, which can occasionally cause a few fragile blocks to be displayed as broken and restored. In most cases, however, this does not occur.
Optional dependencies
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:i4WvDCnD:20otP3tm"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:i4WvDCnD:20otP3tm"
}

