Links
Tags
Creators
Details
1.0.13
Compatibility
Changes
1.0.13 RELEASE
Fixed sorting on Server Racks. The Sorter could only resolve legacy chest-based DSUs and silently ignored the new Server Racks linked via the link module — sorting into racks simply didn't work. The sorter now recognizes Server Racks through the rack registry.
1.0.12 BETA
New: linking racks into a shared network (rack groups / mesh storage).
- Shift+right-click the link module on two racks in sequence to merge them into a shared group — an aggregating terminal now displays and pulls items from every rack in the group as one combined storage.
- Added an access check: you can no longer merge in a rack you don't have access to (previously you could pull someone else's unlocked rack into your own network and drain it remotely).
- Group-member lookups moved from scanning the entire server-wide rack registry to a
groupId → racksindex — group operations are now O(group size) instead of O(all racks on the server). - Group operations (withdraw/insert) are now wrapped in the same lock as single-rack operations, removing a race between mesh writes and a regular hopper/sorter acting on a member rack.
Fixes:
- The DSU Lock now correctly persists its list of authorized user UUIDs — previously the list was lost whenever the lock item was rebuilt from the IO GUI, so adding a second user wiped out the first, and the nickname-change-proof UUID access check effectively didn't work.
- Fixed a race when opening IO settings: left-clicking the Lock to type a name closed the GUI and triggered an item rebuild using stale (unlocked) state, wiping out already-added users.
- Removed a duplicate "Locked" line appearing in the lock's lore on repeated clicks or an interrupted input.
- Removed a duplicate username line appearing in the lore when the same player was added twice.
- Reading the typed username grabbed the wrong item (slot 8 instead of the actual lock slot), losing the owner's name and failing to persist changes when the GUI closed.
- Fixed the Lock silently discarding changes: opening the IO GUI synchronously closed the DSU GUI and erased transient state before the IO close-handler could find it, so nothing was saved.
- The wireless terminal and wall terminal lost their appearance (name/CMD/lore) when linked — the
NBT-writing method mutated the item via
setItemMetafollowed by a direct NBT write on top, which reset the item meta. Switched to copy-based semantics instead. - The wrench caused a duplicate drop when removing a terminal/router frame — a cosmetic filler item and the real item both dropped. Removal is now a single atomic action.
- Breaking a DSU no longer drops redstone dust (the settings button) as a real, pickable item.
LanguageManagernow uses aConcurrentHashMap, and setup returns a success/failure status that blocks plugin startup on a broken language file instead of running on partial translations.UpdateCheckernow filters Modrinth versions by Minecraft version and loader type (falling back to an unfiltered query), avoiding suggesting incompatible updates.BookListener/RecipeCreatornow drop excess items on the ground instead of losing them when the player's inventory is full.DSUManagerread-modify-write operations on a rack are now atomic (synchronized), removing a potential race condition on concurrent modifications to the same rack.- Added an ownership/permission check in the inventory listener, closing another vector for unauthorized access to someone else's rack.
- The crafting table recipe is now also listed as a card in
/es book(using the same result item as the vanilla recipe, so the crafting title gate stays in sync). - Multi-rack / group linking (feature groundwork, completed in 1.0.12). Introduced
MeshStorageViewand theStorageReadViewinterface — a shared "storage snapshot" contract (types + total amounts) for both a single rack and a merged group, avoiding duplicated GUI code (sorting, pagination, rendering). - Link module: rebuilt rack/sorter linking with copy-based semantics — previously a direct NBT write on top of freshly-set Bukkit meta turned the module into a bare Stone Axe with no name or CMD.
getLockedUserUuidsand related lock-ownership logic — first pass of the fix, completed later in 1.0.12.
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:W47kt40y:nZDrVh5u"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:W47kt40y:nZDrVh5u"
}

