create_package_innovation

**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.