Mpi Unpacker 2

MpiUnpacker2 is the other end of MpiPacker2: one MPI_PACK in, two wildcard outputs out, in the slot order they were packed. any_1 is whatever you put in any_1. No selectors, no type juggling, no ceremony.

That's the node. The interesting parts are the two things it does when the situation isn't clean.

Empty slots block, they don't pass nothing

If a slot was left unconnected at the packer, or the pack is shorter than this node's output count, that output gets an execution blocker rather than a None. The branch fed by it stops.

That's a deliberate choice and it's the right one for a graph. Forcing a None down the wire would hand a sampler or a composite a missing value and fail somewhere far away, with an error that describes the symptom and not the cause. Blocking means a half-wired pair simply doesn't run: you get no output rather than a broken one, and the thing that's missing is the thing you didn't connect.

The practical consequence: a silent stop is a wiring problem, not a crash. If a graph finishes with nothing to show and no traceback, walk back up the pack and check the slots are all connected.

A pack longer than the node drops its tail - loudly

Feed a 5-slot pack into MpiUnpacker2 and the last three values are discarded. What you get instead of silence is a console line naming the count:

[MpiNodes] Mpi Unpacker: pack holds 5 slots but this node only has 2 outputs -
slots 3-5 were dropped. Use an unpacker with at least 5 outputs.

That message is worth reading properly, because it's the fix in one sentence. The warning only fires when real values are being thrown away, so an empty tail is quiet - and it names the number of outputs you need rather than pointing at a specific node, since "use Mpi Unpacker 10" is wrong more often than right when a 5-pack in a 2-slot node needs the 5, not the 10.

Inputs and outputs

pack - a required MPI_PACK input. Wire-only, no widget.

any_1, any_2 - wildcard outputs, in pack order. Whatever type you packed comes back out; the type check is skipped on these sockets, which is how a single unpacker node can serve an image and a float without knowing about either.

Nothing to configure. There is no index selector and no "start from slot" widget - if you want the third value of a pack, use MpiUnpacker or MpiUnpacker10. The 2-slot node exists for pairs, because the pair is the case that shows up constantly - width and height, image and mask, a value and its flag - and the 5-slot node spends three empty sockets on it.

Install

Part of MadPonyInteractive/ComfyUi-MpiNodes. ComfyUI Manager → search ComfyUi-MpiNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

Restart, search "Mpi Unpacker 2" (MpiNodes/Logic). No requirements.txt, no models, no pip step. AGPL-3.0 from v1.2.7, MIT for versions up to and including v1.2.6.

Where people get burned

Mismatched pack and unpacker. Same format either way - a 2-pack works in any unpacker, a 5-pack works in the 5- and 10-slot nodes - but a longer pack into a shorter node silently drops the tail and logs it. If you're sorting through console output, that line is usually the answer.

Expecting slot names to travel. They don't. The pack carries values in order and nothing else, so a renamed or repurposed slot in the packer is invisible here. Keep the pairing close together in the graph and label the nodes (rename them - MpiPacker2 and MpiUnpacker2 both take a custom title) so three months from now you know which pack is which.

Assuming a blocked output is a bug. Downstream, ExecutionBlocker looks like "the graph just didn't run this part". Check the pack first. And if you want to test for emptiness explicitly, MpiComparePacks compares two packs slot by slot and MpiAnyChecker will hand you a has_value boolean - both are more useful answers than staring at a stalled branch.