Encoded storage nowadays is a very common thing. And without any new recent developments, it has become rather boring and predictable.
Let's spice it up a little.
What I'm proposing is a new storage solution that may not change the current meta, but would provide an interesting, new storage to interact with, and who knows? Maybe it will even be optimal.
The idea is to create a variable interface encoded system that supports an alternative user interface, user experience, as well as modified input and output mechanisms from conventional encoded storage. This would also be equipped to interface with an interconnected world, including an encoded piston bolt, central bulk storage system, farm output storages, and potentially central digsorts. Please note that though this system would be theoretically variable interface, I will only be discussing a fully call-based interface in this document.
To quote 51Mayday, "halls are long, you can never get the perfect item layout, so on and so forth. I want both density and everything at my fingertips. I also especially hate looking for some random thing for 30 minutes in a chest hall. If the system could just give me what I wanted immediately, I would be much happier with it." Call-based systems improve on this by providing a centralized, easy-to-use interface for the player to access their items quickly and easily. Unfortunately, these systems tend to suffer from issues regarding initial delay, as highlighted in 51Mayday's document here.
To counteract this, we are able to employ the use of a temp storage, functioning like a CPU's cache, which can store items from an external bulk storage for faster access times. When called, the temp storage would send boxes to the player. If there are no full boxes available in this temp storage (which I will now refer to as the "cache," as there are multiple temp storages involved in this system), then it will prompt a different temp storage, which holds partially filled boxes (which I will refer to as simply the "temp") to send its box to be displayed to the player (note that input operations involving this item type will be paused until the box is returned after a cooldown or manual break). After each call, the boxes sent to the player will be deposited back into the cache after a cooldown, and if there are any items or boxes missing, the cache will request those boxes from the external storage.
Without halls bottlenecking speeds and causing an internal distinction between chest hall and bulk item types, we are more free to use alternative sorting techniques. Boxes will be sent to an encoder, which will request its corresponding partially filled box from temp. Note that this "partially filled" box can be empty; if the box becomes filled, it will be replaced by an empty box. If the box fails to be encoded, it will be sent to an FIT unloading array, which will unload the first item type into an overflow with a variable loading array, and if the box still has items remaining after that, the process repeats. When a box is successfully encoded, it is sent to the FIT unloading array and unloaded into a 6x loader with the partially filled box from temp inside. If there are multiple occurrences of the same item type in the unloading array, up to 6 boxes with the same item type can be unloaded at once. Once every box with a single item type has been unloaded, their corresponding 6x loader will be unassigned and the partial box will be stored back in temp. If the cache is lacking full boxes, full boxes from the loading array will be redirected there. If the cache is full, boxes will be redirected to the external storage, where they will remain until called.
(I've already explained the encoded bulk portion, so just pretend it's dynamic and I'll copy and paste that explanation here.)
The external system is managed by an array of request managers. Their purpose is to handle requests, to make sure the system doesn’t get overwhelmed by multiple requests given at the same time. There are two tiers of request manager: 8 that manage the 8 distinct cores of the bulk, which can accept one request at a time, and the main request manager, which governs the other request managers. This request manager can handle two requests at a time. Input can come from the player, box loading array, or the piston bolt network. In any case, the boxes will be whitelisted and be separated by an array of svars (shulker box variable sorters), which will separate each item type into categories. After this operation is complete, one box from two categories from different cores are encoded, and their codes are serialized and sent over to the external bulk. The boxes will then flow through to their respective slices over one dropper line in parallel, asynchronously. This is possible because while each category sends its boxes at 8gt, while the dropper line clocks at 4gt. The categories are staggered by 4gt, and there are systems at the external bulk to ensure that each core only receives the boxes that are meant to go to that core. When both categories empty, the process repeats until there are no boxes left from the input. The system can output boxes to the player, hall, or any peripherals that wish to use it. The player requests boxes by giving the system an item, which it encodes and serializes. The hall requests boxes similarly to the chest hall, except the lists from multiple halls are separate, enabling them to send multiple requests in parallel. Much like the input, when the code unlocks one slice, the clock activates, and the dropper line distributes 54 boxes at 8gt. When another core is activated, the dropper line clocks at 4gt. Requests are handled by the request management system.
Now for the player interface. One proposed solution would be a 5x5 wall of chests, and if a player wishes to call for an item type with more specificity (such as with specific item amount), they can bring the item over to a separate interface, which will call from external bulk directly. If you drop any item inside that chest wall by simply pressing the "drop item" keybind, that will call boxes from the cache, and the first box will be displayed in a box display, while the others will be displayed in a chest. If you call for a different item, or a certain cooldown for player inactivity is reached, the display will break the box and send any other boxes back to the cache. Note that when a player drops or calls an item, it will be returned to the interface.
One interesting thing Data mentioned was support for passive calling. This is an idea that's not new (and was part of the previous storage draft), but I'd like to address it now, as it could be one of the most important aspects of the storage.
Many things built in TMC, excluding decorations, are very repetitive, using much of the same materials to build the same designs. (e.g. bedrock breakers, floor placers, world eaters, etc.) Essentially, passive calling is a kit maker that stores various kits for the player to use. When a player withdraws a kit from the system, a new kit is made. This could be incredibly useful not for just things like startup gear boxes and redstone boxes, but also crafting station boxes and trencher boxes. This is a feature that could greatly improve SMP gameplay, as there would be a lot less manually calling and/or searching for items in the storage.
(I've already explained this as well, so I'm going to copy and paste that explanation here.)
The mass crafting system is a versatile, configurable mechanism that is able to fully utilize the encoded bulk system. There are two inputs: manual and automatic. For manual input, the player inputs the boxes themselves, in a chest for manual and semiautomatic unloading modes, and in a cart-based floor input for automatic unloading mode. For automatic input, the player selects the desired item they wish to craft from a selector panel, and the boxes necessary are called from a silo, which calls from bulk when near empty. In craftContinuous mode, the system calls all boxes from the bulk slices and sends them to the silos. This is only compatible with automatic unloading mode. There are three unloading modes: manual, semiautomatic, and automatic. Manual unloading mode unloads the boxes using the autoCleanContainer rule in Tweakermore, a mod by Fallen_Breath. In semiautomatic mode, the boxes are yeeted without player intervention, but there is no alignment or modulo 4 splitting. In automatic mode, the items are aligned and split across a vertical subchunk using mod4, so the player always is able to craft. There are two loading options: manual or automatic. In manual loading, the player uses autoFillContainer (another rule in Tweakermore) to fill the boxes using the player. The player has the option of sending crafted items into lazy chunks. This is automatically done after 3000gt. In automatic mode, yeeting is automatically slowed down to accommodate the box loaders. In manual or semiautomatic unloading modes, it is possible to select the number of items output in order to ensure the loaders never get overwhelmed (though if the loaders can’t keep up, it will automatically slow down the yeeting interval anyway). There are two storage options, bulk input and player output. Bulk input will input the crafted boxes directly into the encoded bulk, while player output will load chest minecarts with the boxes, which can be sent onto the piston bolt, yeeted and put into a chest array, or input into the storage through either of the two inputs. There are multiple crafting amounts for automatic input mode. The player can select their requested amount of boxes to craft, they can input items into a dropper, or they can select two special modes, craftContinuous and craftRemaining. In craftContinuous mode, the system requests all boxes in the external bulk from the item types in the ingredient recipe, sets the loading mode to automatic, and the output mode to player output. Unlike craftContinuous mode, craftRemaining mode can be enabled alongside player selection of requested amount of boxes to craft, does not request all boxes from bulk, does not set the loading mode to automatic, and does not set the output mode to player output. It detects when a recipe is lacking an ingredient and crafts more of that ingredient, or an alternative ingredient. For example, if the player is attempting to craft pistons but has run out of redstone dust, it can request redstone blocks from bulk, input the extra, and have the player craft the remaining redstone dust. This mode also has compatibility for multi-stage recipes. For example, if the player is attempting to craft shulker boxes, but has run out of chests, and does not have enough planks, it can request logs from bulk, have the player craft the logs into planks, then the planks into chests, then the shulker boxes themselves