Links
Tags
Creators
Details
1.1.1
Compatibility
Changes
Fixes for the item-loss reports and for the mod being active where it should not be.
- Clearer failure when the Sophisticated Core prerequisite is missing. Every entry point now probes
for Core before touching any Core-referencing class and aborts with an explicit message naming
sophisticatedcore, instead of dying inside class initialisation with a bareNoClassDefFoundError(which some launchers surface only as a generic "mod loading failed", with no usable cause). All targets already declare Core in their mod metadata, so a normal loader still blocks the start first. Documentation (README / docs) now states the prerequisite explicitly. - Fabric: fixed item loss when sorting several identical max-stack-1 items (reported with iron
axes / iron leggings / stone shovels: a whole chest of them collapsed to a single item). The
InventorySortermixin that caps each slot's stack limit at the item's own limit embedded a vanilla type in its injection target but was compiled withremap = false. Fabric production runtimes use intermediary names (class_1799), so the injector was never found there: the sorter kept using the container's 64-per-slot limit, merged e.g. five axes into one "stack of 5", and the container truncated it back to one on write-back ¡ª the rest were destroyed. The injector target is now remapped (@At(remap = true), keeping the Core method itself unremapped), and the built refmap mapsItemStacktoclass_1799so the hook actually applies. Forge/NeoForge keep official class names and were unaffected. - Sort results are now validated before being written back. Besides the pre-existing "no item lost" check (per-item totals unchanged), no result stack may exceed what the input legitimately allowed for that item; an oversized stack (exactly the corruption above, which a container would truncate) makes the sort keep the originals instead. A legitimate pre-existing oversized stack still passes.
- New config
transferMainInventoryFirst(defaulttrue). When transferring container items into the player inventory, the mod now fills the 27-slot main inventory before the 9-slot hotbar, matching Sophisticated Core's own transfer. Set it tofalsefor the old vanilla quick-move order (hotbar first). The choice travels with the transfer request, so client and server agree. Applies to all targets. - The whole mod is now inert on Sophisticated Backpacks / Sophisticated Storage screens.
Those screens keep their own sort/transfer handling (including the no-sort "ignored" slots and
memory slots), so the sorter no longer triggers its own sort on them from any entry point:
- Their main screens extend Core's
StorageScreenBaseand their settings screens extendSettingsScreen; all client entry points (sort key, sort/transfer buttons, the settings gear, the disable toggle, slot-highlight decoration and even the search-box tooltip hint) now bail out on both. - Server-side guard:
CoreUtils.executeSort/executeTransferskip any openStorageContainerMenuBase/SettingsContainerMenu, so even a mismatched or third-party client cannot make the sorter touch a Sophisticated container.
- Their main screens extend Core's
- Fixed item loss ("swallowing" items) when sorting a high-stack inventory. The generic sort
feeds stacks through Core's
InventorySorter, which places items back at the vanilla 64-per-slot limit; a high-stack item (from a stack upgrade) then needs many slots, and Core silently drops the overflow when there are not enough. The sort result is now verified against the per-item totals taken before the sort and is discarded when anything would be lost, so sorting can never destroy items. Applies to the shared backend and the 26.1 adapter. - Fixed the sort/disable keys doing anything at all on a Sophisticated screen, which previously made the key open-sort behave like "sort the player inventory".
Note: the two entries above and the first two entries of this release are the fixes for the "sorting swallows items / only one item left" reports. The root causes were distinct:
- Fabric only ¡ª a mixin lost its obfuscation mapping in production, so max-stack-1 items were merged into one invalid stack and truncated (iron axes / leggings / shovels all reduced to one).
- All targets ¡ª the generic sort could not represent high-stack items (stack upgrades) or items that needed more slots than were free, and the overflow was dropped.
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:2LPywrDb:JEEgfXzG"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:2LPywrDb:JEEgfXzG"
}

