
partialkeepinv
Keeps shulker boxes, container items (ender chests, bundles) and all non-stackable gear (tools, weapons, armour, elytra, etc.) on death while everything else drops normally. Adds configurable 1–5 level XP loss and light armour durability damage on each dea
1.0.1
Compatibility
Changes
1.0.1 – Config & container keep update
New features
-
Added a config.yml to control behaviour without recompiling:
keep.shulkers– toggle keeping shulker boxes on death.keep.non_stackable_items– toggle keeping all non-stackable items (tools, weapons, armour, elytra, etc.).keep.containers– toggle keeping extra container-like items (see whitelist below).xp_loss.enabled,xp_loss.min_levels,xp_loss.max_levels– configure how many XP levels are lost on death.armor_damage.enabled,armor_damage.percent– configure whether armour takes extra durability damage on death and by what percentage.
-
Introduced a container whitelist:
- New
containers.material_whitelistsection inconfig.yml. - By default includes:
ENDER_CHESTandBUNDLE. - Any material listed here is always kept on death (as long as
keep.containersis true), so items that store or access other items are preserved.
- New
Behaviour fixes / improvements
- Fixed an issue where ender chests (and other stackable “container-type” items) were not kept on death.
- Settings are logged on startup so you can easily see which options are active.
Notes for updaters from 1.0-SNAPSHOT
- If you already had a
config.ymlfrom the previous version, it will not be overwritten.- You should either:
- Delete the old
plugins/parialkeepinv/config.ymland let the plugin regenerate it, or - Manually add the
xp_lossandarmor_damagesections (andcontainers.material_whitelist) to your existing config.
- Delete the old
- You should either:
- New installs get the full config with all sections by default.
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:ZootlZ8S:EDq5CxfS"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:ZootlZ8S:EDq5CxfS"
}
