**Mechanical Power's Package & Logistics Addon Mod: Adds new mechanics to Create's package system.**
**Shared Package Pool:** Multiple machines on the same container no longer have a single one monopolizing the entire order. Sorted/packed packages enter a world-level shared pool bucketed by container (multi-block containers use a stable UUID, others use a location key), and each idle machine actively pulls 1 to send per tick. N machines ≈ N× speed, with natural dynamic balancing (a jammed machine automatically stops pulling packages, and the flow goes to idle siblings).
**Routing by source:** Each package in the pool records whether it was produced by a re-packer (Repackager) or a packager (Packager), and machines only pull packages from their own source. So ordered packages sorted by a re-packager won't be taken by a packager attached later—they will always be sent out from the re-packager's own side. Machines of the same type still share the same queue, so "N re-packagers ≈ N× speed" is unaffected.
**Packagers also participate (not just re-packagers):** Packages assembled by a packager in `attemptToSend` go directly into the pool instead of first being stuffed into its own private queue; backlog already sitting in a private queue is also handed over to the pool to be sent out by other machines on the same container. Redstone only controls "re-packagers pulling packages": after redstone is cut, a re-packager stops pulling from the pool within at most 0.5 seconds, and automatically resumes when powered again (this applies to both Create's re-packager and Create: FluidLogistics' fluid re-packager); ordinary packagers ignore their own redstone and always pull packages as usual (packagers on a shared container are often just the shipping end and have no redstone connected at all). The "hand-in" step ignores redstone for any machine—a package a machine has already produced will definitely be handed to the pool; adding a redstone gate would lock packages inside the unpowered machine, manifesting as "item swallowing." The pool is stored in the save, so packages are not lost during power outages.
**Partial reassembly:** It doesn't wait for all material fragments of an order to arrive; as long as the arrived fragments are enough to craft at least once, work starts early; unused leftovers are held in the save and burst out in full when the container is broken, keeping materials conserved throughout.
**The shared pool follows the save, not the block:** Breaking a machine does not burst the pool; partially dismantling a multi-block container lets the remaining blocks inherit identity via UUID, and the order keeps running; only breaking the last block bursts the entire pool.
**Missed-extraction fallback (including across saves):** Each pool key's "where it last appeared" hint persists with the save (a separate SavedData, without changing the save format of the pool or the leftover tracker), so after a restart, when the chunk loads, it can still determine whether the container still exists and burst the missed pool into drops in full, rather than letting packages rot in the save.
**Container compatibility (all containers):** Identity determination is not hard-bound to specific classes; it is divided into three paths by container type:
| Container type | Identity | Dismantling cleanup |
|---|---|---|
| Multi-block containers (Create's vanilla vault and fluid tank, Create: Connected's vertical vault Item Silo, etc.) | Stable UUID attached to that BE (the only thing stable across reshape) | `ConnectivityHandler.splitMulti` + neighbor UUID scan, then connectivity walk as fallback (no radius limit, covering fluid tanks whose height comes from the `fluidTankMaxHeight` config), distinguishing "partial dismantling" from "full dismantling" |
| Networked storage (Create: Storage's Simple Storage Network) | Network anchor (controller) location key | Breaking a chest in the network: the computed location key doesn't match, pool untouched; breaking the controller: exactly hits the anchor key, entire pool bursts |
| All other containers (vanilla chests/barrels, storage blocks from other mods, etc.) | Location key (deterministic UUID derived from dimension + coordinates) | `LevelChunk.removeBlockEntity`—triggers only when the block is truly removed; chunk unload does not mistakenly burst the pool |
Single-block containers need no adapter mixin at all; containers from any mod work out of the box. Multi-block containers still need an adapter mixin of about 60 lines following `mixin/compat/ItemSiloBlockEntityMixin.java` because identity must be preserved across reshape; compatibility mixins live in a separate config `create_package_innovation.compat.mixins.json` (`required=false`, `defaultRequire=0`), and when the corresponding mod is not installed they only log a warning without blocking startup.
**Fluids (Create: FluidLogistics):** A fluid packager's `targetInventory` is only its item side (the filter even excludes portable fluid interfaces), while the real storage is the fluid tank faced by `fluidTarget`, so identity is counted by the latter (`FluidTargetAccessor`, implemented in a compat mixin). However, Create's fluid tank itself occupies the `extraData` channel (passing a Boolean-type window flag), so the milk-tank adapter deliberately does not override the `extraData` trio nor hook `notifyMultiUpdated`: instead, the UUID is preserved across reshape by "writing the old UUID back to surviving parts along connectivity when splitting" (otherwise a re-formed controller would mint a new UUID first and turn the old pool into an orphan). Storage such as AE2/RS that does not yet provide a network anchor is still counted as an individual block for identity.

