God Damn Repackager

⚠️ ALPHA (0.3.0)
This mod is in early testing. It uses a Mixin to modify Create's repackager core logic and
has not yet undergone large-scale, long-term stability testing. Back up your world before
using it. Bug reports are welcome on the project page.

ℹ️ If you used 0.2.0: 0.2.0 could cause "only some repackagers work after placing an order"
(e.g. 6 of 9) in an existing world, requiring you to re-place the repackagers. Fixed in 0.2.1 —
just upgrade, no re-placement needed. See Known Limitations.

The Problem

In vanilla Create 6.0+, when you place a large crafting order through the Stockkeeper for your
crafter array (e.g. "craft 1000 iron blocks"), the entire order is processed by a single
Repackager. Even if your input vault is surrounded by repackagers, only one of them does any
work — the rest sit idle. A repackager emits only one package per second (20-tick animation
cycle), so large orders take a very long time.

God Damn Repackager makes all repackagers attached to the same input vault share the work.
N repackagers ≈ N× throughput.

Speed Comparison

Usage

No configuration required — works out of the box. Build your crafter array as usual:

Stockkeeper ──order──> Frogport ships materials ──> Input Vault (holds material packages)
                                                          ↓
                                            Multiple Repackagers (redstone block = always on)
                                                          ↓
                                            Packager (unwraps) → Mechanical Crafter → Output

As long as multiple repackagers are attached to the same input vault, this mod automatically
parallelizes them. Repackagers must be placed against a Create Vault.

How it works

The mod uses two complementary layers:

1. Snapshot allocation — When a repackager assembles an order's packages, it would normally dump
   the whole batch into its own send queue. The mod intercepts this and instead distributes the packages
   across all repackagers on the same vault, weighted by current queue depth (shorter queue = more work).
2. Dynamic rebalancing (new in 0.3.0) — Every ~0.5s, if one repackager is badly backlogged while
   another is idle, a slice of the backlog is moved from the busy one's queue tail to the idle one's. So
   even if one repackager's downstream path clogs, its work is picked up by idle siblings and overall
   throughput isn't dragged down by a single stalled machine. Rebalancing is order-preserving (only the
   queue tail is touched, and only when severely imbalanced), so it never scrambles a craft.

Installation

1. Minecraft 1.20.1 + Forge 47.x
2. Install Create 6.0.x (required dependency; tested with 6.0.8)
3. Drop the jar into .minecraft/mods/

Upgrading from 0.2.0? Just replace the jar. 0.2.0 used to require re-placing repackagers in an
existing world; 0.2.1 fixed this — no re-placement needed after upgrade. See
Known Limitations.

Compatibility

• ✅ Tested: MC 1.20.1 + Forge 47.2.0 + Create 6.0.8
• ✅ Tested in modpack environments and on multiplayer servers alongside other mods — no conflicts
• ⚠️ Targets the Create 6.0.x logistics system only; not compatible with Create 0.5.1 and earlier
• ⚠️ Forge only (a Fabric port may come later)

Known Limitations

• Re-place repackagers after installing into an existing world. (Fixed in 0.2.1) 0.2.0 could
  cause "only some repackagers work after placing an order" (e.g. 6 of 9) in a world that already existed —
  far more often on multiplayer servers than in fresh single-player worlds. Cause: 0.2.0 identified sibling
  repackagers by the identity (==) of the Forge capability instance they cached, which is rebuilt whenever
  the vault's capability is invalidated, so repackagers placed before the mod existed could hold caches
  pointing at different generations and fail the check. 0.2.1 fix: siblings are now matched by Create's
  InventoryIdentifier value equality (for vaults: a Bounds(BoundingBox) record comparing only the
  multiblock's corner coordinates), which is stable across capability rebuilds. Upgrading to 0.2.1 resolves
  this — no re-placement needed. (Technical detail in TECHNICAL.md §3.7.)
• The current implementation is "load-balanced snapshot allocation": at the moment a repackager
  assembles an order's packages, it decides who gets what based on current queue depth. This is
  sufficient for the vast majority of real cases; in extreme edge cases a repackager that goes
  idle after allocation won't "steal" work from another's queue.
• Repackagers must be attached to a Create Vault. Other containers (Crates, vanilla chests) are
  theoretically supported but not fully tested.

License

MIT License — free to use, modify, and distribute. Source code and a full technical writeup
(architecture, dev pitfalls, roadmap) are on the project GitHub.

Credits

• Create and its author simibubi —
  an outstanding mod that this project builds upon.