EvaluateListMultiple3

The list-flavored sibling of EvaluateMultiple3: three inputs (in1–in3), three outputs (out1–out3), but every one of them is list-typed. Feed it batches - a list of image sizes, a list of captions, a list of seeds - and the expression runs once per element across all three lanes simultaneously.

What "element-wise" means here

The node's own default expression text says it plainly (translated from the author's Chinese): the expression runs element-wise, and any output that comes back None for every single element gets dropped when the results are merged back into a list. Practically: if you're deriving out1, out2, out3 from the same triplet of per-item inputs - say, a width, a height, and a label for each image in a batch - this node applies your logic to item 1's (in1, in2, in3), then item 2's, and so on, and hands back three parallel lists the same length as what you fed in.

Inputs and outputs

• expression (multiline STRING) - pre-filled with the element-wise hint; replace with your logic.
• input_count (INT, 1–20, default 3) - shared range across the whole Evaluate/EvaluateList family; this "3" is a starting point, not a ceiling.
• print_to_console - debug echo.
• Optional: in1, in2, in3 (type *).
• Outputs: out1, out2, out3 (all is_list: true).

The usual caution

Same as every node in this family: real Python, executed as written, no allowlist or AST restriction stated anywhere in the pack. Write expressions you actually understand, and be extra deliberate about it here - a bug in an element-wise expression doesn't just break one value, it breaks every item in the batch it runs across.

Installing it

ComfyUI Manager: search RuiquNodes, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/ruiqutech/ComfyUI-RuiquNodes

then restart. No extra dependencies.

Common issues

One of the three output lists is entirely empty. Per the node's own documented behavior, an output column that's None for every element in the batch gets skipped at merge time. If you were expecting real values back, check that your expression is actually setting that outN for at least some elements.

The batch length doesn't match what you expected. Confirm all three inputs you're wiring in are genuinely the same length - an element-wise expression assumes they line up, and a mismatch is a logic bug in your graph upstream of this node, not something this node itself will catch for you.

Debugging inside a batch. print_to_console prints per element as the expression runs, which is the fastest way to see exactly where in a long list something goes wrong.

Mixing this up with EvaluateMultiple3. If none of your inputs are actually lists - you've got three plain values, not three batches - you want the non-list EvaluateMultiple3 instead. Wiring a single value into this node's in1 still technically works (you get a one-element list back), but it's the wrong tool for the job and adds list-handling overhead you don't need.