Yumil Block Selector

Yumil Prompt Parser gives you all the ###_Path(...).Value(...).Text(...)_### blocks from a prompt as one JSON blob. This node is how you get one of them out. It's the second stage of the pack's pipeline: parser → block selector → image loader / value reader.

Why bother with a selector at all? Because a single stored prompt in Yumil MPM can describe several things at once - a character reference here, a pose reference there, a ControlNet condition somewhere else. The parser collects them all, and the selector lets you address them individually by index. If your prompt has three blocks and you want to load all three reference images, you drop in three Block Selectors, each set to a different index, and each one feeds its own branch of the graph. Same parsed data, multiple consumers, no repetition. That's the plumbing-layer pattern done right: one upstream source, fanned out where you actually need it.

How it works

It deserializes the PARSED_DATA JSON from the parser and pulls out the block at the index you give it. Simple, with one important detail: the index is zero-based, so the first block in the prompt is index 0, not 1. If you ask for an index past the end, it raises a clear error telling you how many blocks actually exist (e.g. "Block index 2 out of range. Only 1 block(s) found (indices 0-0)"). That error is your friend - it means the prompt didn't have the block you thought it did.

Inputs and outputs

• parsed_data - connect this to PARSED_DATA from Yumil Prompt Parser. It's a STRING socket, so if you see "can't connect," you're probably wiring from the wrong output.
• index - zero-based block index, 0–99.

The outputs are the block's guts, pre-split for you:

• path_0 … path_3 - the individual paths from Path(...), split on commas. If a block has only one path, path_0 holds it and the rest are empty strings.
• path_count (INT) - how many paths the selected block had. Useful if you want a node downstream to behave differently based on how many references were supplied.
• value - the raw key=value parameter string, untouched (e.g. strength=0.8,mode=ipadapter). Feed this into Yumil Value Reader to pull out individual keys.
• text - the block's associated text.

A block with no paths just yields empty path_* outputs; the node doesn't error on that, only on a bad index.

Where it fits and what trips people up

Typical wiring: path_0 → Yumil Image Loader's path input to actually load that reference image, and value → Yumil Value Reader to extract strength or mode for the ControlNet/IPAdapter node. The path outputs being capped at four is a real limit to remember - if a Path(...) lists five files, only the first four come out as separate outputs (though path_count will honestly report five).

Installing it is just the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/maigonia/comfyui-yumil-mpm.git
cd comfyui-yumil-mpm
pip install -r requirements.txt

or ComfyUI Manager → search comfyui-yumil-mpm → restart. Only dependency is requests; this node is pure parsing.

The other gotcha is subtler: the selector reads whatever PARSED_DATA the parser produced last run. If you change the prompt but the parser's output didn't change (same block count, same index), the cache may skip everything downstream - but that's fine, because the content is the same anyway. If you ever suspect a stale block, re-run the parser; IS_CHANGED behavior on this one is standard, so a genuinely different prompt re-propagates normally.