Interactive Selector (with parameters)

The plain InteractiveSelector only shows you an image and passes that image through when clicked. Fine, until your branches aren't just images - say each candidate came with its own latent you'd want to keep sampling on, or a mask, or the specific prompt string and seed that produced it. That's what InteractiveSelectorWithParameters is for: same click-to-choose button, but it carries a whole bundle of data - image, latent, mask, string, int, and float - as one package, so picking a branch doesn't mean losing everything except the picture.

It pairs exclusively with InteractiveSwitchWithParameters downstream - the plain InteractiveSwitch won't accept this node's output, because the connector type carries more than the plain selector's.

How it works

Same mechanics as the plain selector: this node shows the image on the node itself with a clickable button, and clicking it flips the internal selected state to true. What's different is everything else you wired into it - a latent, a mask, a string, an int, a float - travels along for the ride, bundled into the single selector output. When the corresponding InteractiveSwitchWithParameters detects this selector was the one clicked, it unpacks all of that back out as separate outputs on the switch side.

This is the version you reach for once you've moved past "pick an image" and into "pick a whole configuration" - e.g. three different img2img setups where each candidate has its own denoise-relevant latent and its own caption, and you want the one you approve to keep all of that attached rather than re-deriving it after the fact.

The inputs and outputs that matter

• images (optional, IMAGE) - what's previewed on the node; also the thing forwarded if chosen.
• parameter_latent (optional, LATENT), parameter_mask (optional, MASK), parameter_string (optional, STRING), parameter_int (optional, INT), parameter_float (optional, FLOAT) - the extra payload. None of these are required; wire in only what a given branch actually needs. If you leave one unplugged on every selector feeding a switch, that output on the switch just won't carry anything meaningful for it.
• selected (boolean, default false) and propagate_deselect (boolean, default true, required) - same as the plain selector: selected is the button state, and propagate_deselect cascades a deselect forward to selectors further down the workflow so a multi-stage choice doesn't leave stale picks behind.
• selector (output, interactive_images) - plug this only into an InteractiveSwitchWithParameters slot.

How to install it

Via ComfyUI Manager: search "ComfyUI-Interactive", install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/lquesada/ComfyUI-Interactive

No requirements.txt, no models to fetch - same lightweight pack as the rest of the nodes here.

Common issues & troubleshooting

I only see the image update, not the latent/mask/etc. Those parameter outputs only populate on the switch side once this selector's been clicked and the switch has resolved which one won. Check you've wired the switch's parameter_* outputs onward, not the selector's inputs - the selector just holds the data until picked, the switch is what releases it.

I wired this selector into a plain InteractiveSwitch and it didn't connect. That's expected - the two "with parameters" nodes only talk to each other, and the plain pair only talks to each other. Mixing them isn't supported; use InteractiveSwitchWithParameters here.

Same auto-queue and Anything Everywhere caveats as the plain selector. Keep auto-enqueue off with an empty queue so the pause actually holds, and avoid routing the selector→switch link through cg-use-everywhere nodes, which can break state propagation between them.

Unused parameter slots feel wasteful to leave empty. That's normal - most workflows only need one or two of the five parameter types per branch. There's no penalty for leaving the rest unplugged.