LZ Pipe Unpack
Get your fourteen values back out of one wire
- lz_pipe
- MODEL
- CLIP
- VAE
- positive
- negative
- LATENT
- positive_text
- negative_text
- width
- height
- ckpt_name
- ckpt_hash
- lora_name
- lora_strength
- lora_model
- lora_weight
The pack side of the pipe system is obvious - shove everything into one wire. The unpack side is what makes it usable with normal ComfyUI nodes, because a LZ_PIPE connection means nothing to a stock KSampler. LZ Pipe Unpack takes a single lz_pipe and hands you back fourteen separate outputs: MODEL, CLIP, VAE, positive, negative, LATENT, positive_text, negative_text, width, height, ckpt_name, ckpt_hash, lora_name, and lora_strength.
That's the full key set the pack writes, laid out as individual sockets. Wire whatever you need into whatever stock node expects it - model into a KSampler, conditioning into a CLIPTextEncode, VAE into a VAEDecode - and ignore the rest. It's a dumb, mechanical node: no options, no widgets, just a one-to-one expansion of the dict.
What happens when the pipe is missing something
Because every pipe input is optional (you can pack a pipe with nothing but a model), the unpack has to handle gaps. The source shows the defaults: missing strings come back as "", missing width/height come back as 0, and missing ckpt_name/ckpt_hash come back as the string "Unknown". That's a useful tell when you're debugging - if you see "Unknown" flowing out of an unpack, you now know the pack never had that value, which usually means the loader didn't run through this pack's own loaders or nobody set the field.
The realistic workflow
The pipe pattern in this pack is: LZSimpleCheckpointLoader → LZPipePack (or the loader's own built-in pipe) → sample → LZSaveImageAndLog. But the moment you want to use a node outside the pack - say, a specific sampler or a controlnet that takes raw conditioning - you'll find an unpack sitting between the pipe and that stock node. It's the adapter layer, and it's exactly why the pack is usable in mixed graphs rather than a closed ecosystem.
Where people get tripped up is the stale context problem, and unpack is where it becomes visible. You unpack MODEL off a pipe that was assembled before a LoRA got applied, and the sampler runs the base weights - no error, no warning, just the wrong model. The KB's plumbing notes hammer this: pipes hide which version of each value is inside, and unpacking a stale bundle is a silent failure. If your output looks like it ignored a LoRA or a latent swap, trace which pack produced the pipe that feeds this node, not the sampler.
Installing it
Standard pack install:
cd ComfyUI/custom_nodes
git clone https://github.com/liz-ils/ComfyUI-LZNodes
Restart ComfyUI (or ComfyUI Manager → search "ComfyUI-LZNodes"). No extra Python packages, no model downloads.
A quick sanity tip
Since unpack gives you every value in the bundle at once, it doubles as a debug tool. Plop one on the end of any pipe, and you can see exactly what rode along - including whether ckpt_hash actually got filled, which is the field LZSaveImageAndLog will print in its log file. If the hash shows "Unknown," your provenance trail is broken upstream.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| lz_pipe | LZ_PIPE | — |
Outputs (16)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |
| VAE | VAE | — |
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| LATENT | LATENT | — |
| positive_text | STRING | — |
| negative_text | STRING | — |
| width | INT | — |
| height | INT | — |
| ckpt_name | STRING | — |
| ckpt_hash | STRING | — |
| lora_name | STRING | — |
| lora_strength | STRING | — |
| lora_model | STRING | — |
| lora_weight | STRING | — |