ND Variant Values (internal)

A selector that picks which variant to keep, wired into the thing that produces the variants, is a cycle. ComfyUI won't allow it, and rightly so. This node is the escape hatch that lets it work anyway - hidden from the search menu, added by the frontend, and never something you place by hand.

What it is

A tiny carrier of three values: the toggle state, the selected index, and the upscale flag. No graph inputs. When you queue a run, the frontend reroutes the selector's output through this node and fills it with whatever was on screen at that moment. Downstream nodes therefore receive the same parameters bundle they'd have received from the selector, but the connection no longer points back at the selector - so there's no loop.

The docstring in the pack says it plainer than I can: the node "has no inputs from the graph, only the values shown in the selector at queue time, so a selector can feed nodes that also feed it (no circular connection), while consumers still receive the same parameters wire."

Its inputs, for completeness

You won't set these, but they explain the semantics precisely:

• multi_variant (BOOLEAN) - the Multi-Variant toggle as it stood when the prompt was sent.
• value (INT) - the index. Full 32-bit range here, because it's carrying both selectors' notions of "which one".
• upscale (BOOLEAN) - the upscale flag for this run.
• value_name (STRING, default value) - what to call the index inside the bundle: selected_index for the preview selector, value for the slider one. This is how one helper serves both nodes without them disagreeing about field names.

Output: params, an ND_PARAMS bundle with those three fields - exactly the shape the selector's own output claims to have. Any Unpack downstream sees multi_variant, the index field and upscale, and doesn't care that it came from a helper.

The one behaviour worth knowing

Snapshot, not live link. The values are captured when the prompt is queued, so what flows downstream is what you saw in the node at that instant - not whatever you click after the run starts. That's the correct choice (a half-finished run shouldn't change its mind about which variant it's upscaling) but it does mean clicking around during a run has no effect on the run in progress.

Practically, this shows up in one place: you queue, then immediately click a different thumbnail, and the result is still the original. Queue again. There's nothing broken.

Where you'll actually run into it

In API-format exports. The resolved prompt contains NDVariantValues with real numbers baked in. That's the useful form - if you're scripting ComfyUI and want to reproduce a specific selection, editing value there is legitimate and works. Just don't confuse the export with a UI workflow and try to drag the helper onto the canvas afterwards.

In a "missing node type" message. Same as any pack-internal node: the install doesn't have Neural Dreamer Nodes, or the browser tab hasn't picked up the frontend code yet.

When someone tells you a circular connection error is impossible here. They're right with this node in the prompt, and wrong if it's been deleted or if the pack's frontend didn't run - for instance, if you edited the workflow's JSON by hand and removed the helper. The cycle protection lives in the frontend pass that inserts it, not in the node graph you can see.

Install

Bundled with Neural Dreamer Nodes (v1.1.0, MIT). No Python dependencies, no models:

cd ComfyUI/custom_nodes
git clone https://github.com/neural-dreamer/ComfyUI-NeuralDreamer-Nodes.git

Restart and refresh the tab. It's marked DEV_ONLY in the pack, so it deliberately stays out of the node search - you have it the moment the pack loads, whether or not you can find it in the menu.

Common issues

I can't find it in the search. Correct and intentional. It exists only inside queued prompts.

I added one manually and things got weird. It has no graph inputs, so a hand-placed copy has nothing to read - you'd be feeding downstream nodes defaults. Delete it, use the selector.

The downstream value is a number I can't trace. It came from a selector's UI state, and the same number is visible in that selector at queue time. Look at the selector, not the helper.