Tags
Creators
Details
Licensed CC-BY-4.0
Published 4 months ago
Updated 10 hours ago
All versions
0.5.2+mc26.3-neoforge
Beta
v0.5.2 (MC 26.3 Neoforge)10 hours ago 2
Uploaded by
Compatibility
Minecraft: Java Edition
26.3
Platform
NeoForge
Supported environments
Dedicated servers only
Changes
0.5.2 — 2026-10-02
Double chests now follow vanilla's rules exactly. Thanks to TheArchictect for the detailed report.
- Fixed: an unnamed double chest showed "Chest" as its title. It now shows "Large Chest", like vanilla.
- Fixed: a double chest opened if you clicked its free half while the other half was blocked (for example by a solid block or a sitting cat on top of it). It now stays shut, like vanilla.
- Fixed: a double chest with only one half locked opened from the unlocked half. Both halves now have to be unlockable.
- Fixed: if only one half was renamed, its name could be lost. The menu now uses vanilla's name rule: the first named half wins, and with no names it's "Large Chest".
- The two halves now appear in the same top-and-bottom order as vanilla. On some existing double chests your two halves may swap places once; nothing in them is lost.
- Applies to every file (Fabric, NeoForge and Forge).
Also in this release (from 0.5.1, which didn't get a separate release):
- Fixed: the Fabric builds now work in singleplayer, LAN and e4mc worlds. Every Fabric file was
marked server-only, so Fabric skipped SlashLoot in any game client, including the built-in server
that runs a singleplayer world. To use it there, put SlashLoot and Fabric API in your own
mods/folder. Friends who join your LAN world don't need it. - On a dedicated server nothing changes: only the server needs SlashLoot, and players connect with an unmodified game. Having it installed on the client as well (for example in a modpack) is harmless.
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:mRZVkEL7:Ek8zlT0W"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:mRZVkEL7:Ek8zlT0W"
}

