Tags
Creators
Details
Licensed ARR
Published 3 months ago
Updated last week
All versions
0.1.13
Release
Sorted 0.1.13 (fabric)2 weeks ago 96
Compatibility
Minecraft: Java Edition
26.2
26.1.x
Platform
Fabric
Supported environments
Client-side
Required content
Changes
Added
- Nearby Quick Stack / Quick Fill / Smart-Empty show their progress on the action bar — "Reading chests (2/8)…", "Quick-stacking (1/3)…" — and finish with a summary of how many chests received or gave items. All versions.
- A slow server is called out while a nearby transfer waits on it. After a second without an answer the action bar says the server is slow to open chests; while a late reply is being waited for it counts the seconds, so a stalled-looking transfer reads as the server's pace rather than the mod hanging. All versions.
Changed
- Nearby transfers on servers are quicker. A chest whose assigned items have already left your inventory is no longer opened at all, so a run ends the moment there is nothing left to move instead of visiting every planned chest. And the half-second settle the sorter waits after its clicks is skipped for transfers, which only shift-move and never touch the cursor the settle exists to check. All versions.
Fixed
- Chest labels (and cached contents) can no longer get swapped between neighbouring chests by a nearby transfer. When a chest was slow to open, the transfer waited a fixed moment and went on to the next one — but the server answers opens in order, so on a lag spike the slow chest's reply arrived after the next chest had been asked for and was taken for it: two plain chests can't be told apart by their menu. Its items went into the wrong chest, and its contents were recorded in the cache under the other chest's position, which is what the glance labels then showed. The transfer now never asks for another chest while a reply is still outstanding: it waits for the late reply (which is closed unused), then retries that chest, and gives up with a message only if the server stops answering for ten seconds. All versions.
/sortedteston a server now shows the loaded inventory immediately. The creative slot packets it sends update the server only; the client's inventory was left untouched, so the slots looked empty until something forced a resync. All versions.- Nearby Quick Stack on servers no longer trips over your own inventory screen — the cause of the mess, the missed items and the flashing chest GUIs. The nearby buttons sit in the inventory screen, which stays open while chests are visited. The "chest opened visibly" fallback only asked whether a container screen was showing — and the inventory is one — so it fired a tick before the server ever answered, "handled" the chest with the old blind quick-stack, and moved on. The real reply then arrived in the wrong state: treated as the next chest (items into the wrong chest), or with its suppression already used up (the chest GUI flashing). Both open paths now run one shared, validated handler, and the fallback only accepts a chest screen that was not there when the transfer started. Singleplayer never used this path, which is why it was fine there. All versions.
- A single stray item can no longer turn a junk chest into a Quick-Stack "home". A chest technically "held" an item even when one stray unit of it sat lost among a chestful of junk, so quick-stacking sent your items there — scattering a material instead of grouping it. A chest now only counts as a home when it holds a meaningful amount of the item or its material relative to what else is in it: a lone stack of diamonds in an otherwise empty chest clears the bar easily, one stray diamond in a mess chest does not. Items with no real home stay in your inventory. All versions.
- Quick-Stack re-checks each chest's live contents before depositing. The route is planned from the cache, and a cache entry can be wrong in ways no chest-open reveals — a hopper drained it, a plugin changed it, a command rebuilt it. Each planned deposit is now confirmed against the chest's actual contents at the moment it opens; items whose chest no longer holds their kind stay in the inventory, and the fresh contents recorded on close correct the next plan. All versions.
/sortedtestseeds the container cache with the scene it builds. The test scene is written server-side without ever opening a chest, so the cache kept whatever it held for those positions — including chests the background scanner caught half-built — and quick-stack planned from that garbage (typically moving only one of the three materials). The build now records every chest's exact contents into the cache when it finishes. All versions.- Nearby Quick Stack now actually moves items on Minecraft 26.x. The move pass selected which inventory slots to deposit using the wrong slot numbering (the menu's, not the inventory's) — for a double chest no slot ever matched, and for a single chest only the top row of the main inventory did. That is why a normal quick-stack often moved nothing. The 1.21 versions were not affected by this particular bug.
- Nearby Quick Stack no longer re-opens every chest on every run. Two causes made it a slow, lid-popping walk-through: cached chest contents were only trusted for 30 seconds before being re-read, and — worse — the transfer's own chest-opens were mistaken for another player's (their lid animation echo), invalidating the very cache entries it had just refreshed. The transfer now trusts the cache exactly as far as the background scanner does (with event invalidation keeping it honest) and tags its own opens, so with a warm cache it plans instantly and only opens the chests that actually receive items. The "Scan freshness" setting keeps its escape hatch: 0 still means "always open every chest". All versions.
- Chests are still sorted after a nearby deposit, but only the chests that received something. Every chest in reach used to be opened and fully re-sorted; now only chests that actually take items are opened, and each of those is tidied afterwards in its remembered layout (or an inferred one). All versions.
- Sorting works on servers again. Sorting fires clicks far faster than a server confirms them, so the server answers nearly every click with a full container resync; those resyncs kept arriving after the last click and briefly rewound what the client believed the container — and the cursor — held. The cleanup that runs after a sort read that rewound state, saw a phantom stack "stuck" on the cursor, and clicked it back into the chest: a rogue click that scrambled the layout and left the client convinced the cursor was full, at which point every later sort silently refused to run. On a server, the mod now waits half a second after its last click for the server to catch up before it reads anything back, cleans up, or chains a follow-up action. Singleplayer is unaffected. All versions.
- A sort that a server partially blocks now repairs itself. Anti-cheat plugins and interaction rate limits silently cancel some of the sort's clicks, which used to leave the container half-sorted with no correction. After each sort settles, the result is checked against the intended layout and only the missing moves are re-issued, up to two repair passes. This covers container sorts, inventory sorts, and the sort that runs after a quick-stack. All versions.
- Nearby Quick Stack on servers no longer moves items into the wrong chest. When a chest was slow to open, the transfer gave up after one second and moved on — but the late reply was then mistaken for the next chest's answer, so that chest's items were deposited into whichever container happened to respond, and its contents were recorded in the cache under the wrong position, corrupting future routing. A timed-out open is now discarded and closed when it finally arrives, the transfer waits out a quiet gap before opening the next container, and an answering menu is checked against the shape of the block that was actually clicked (shulker, single, double) before anything moves. All versions.
- A chest that is slow to open is retried instead of silently dropped. The per-chest window is now two seconds instead of one, and a chest that still fails gets one more attempt at the end of the run — previously it simply fell out of the plan, which is why a chest that obviously should have received your items sometimes got nothing. All versions.
- Double chests are planned as one container on servers. Each half used to be treated as a separate chest: the half not carrying the cache entry looked like an unknown, empty 27-slot chest, stealing deposits from the chests that actually held the matching items, and the same double chest was opened twice per run. Both halves now collapse into one 54-slot container, and the transfer clicks whichever half is actually in view. All versions.
- Chests that cannot be opened are left out of nearby transfers. A chest with a solid block sitting on it can't open, so every run stalled on its timeout and any items routed to it went nowhere. Such chests are now skipped up front. All versions.
- Ender chests are no longer indexed by position via nearby transfers. One path still recorded their contents against the block position — the cache warm-up that runs after a nearby transfer touches a container. It now skips them, like every other recording path has since 0.1.11. All versions.
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:vtsGVHan:FvX8dinW"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:vtsGVHan:FvX8dinW"
}



