ControlAltAI: Integer Settings Advanced

Three radio buttons wearing a checkbox costume. Flip one on and the other two switch themselves off, and the node hands out 1, 2 or 3 depending on which is lit - the value you feed into ControlAltAI: Switch (Three Way) to pick a branch.

It's the three-position version of Integer Settings, and like its two-state sibling it does not output 0. setting_1 → 1, setting_2 → 2, setting_3 → 3.

How it works

The Python side is deliberately dumb. It checks from the top down:

if setting_3:
    return (3,)
elif setting_2:
    return (2,)
else:
    return (1,)   # setting_1 or fallback

Mutual exclusion is not enforced there - it's enforced in the frontend, by a small JavaScript extension the pack ships (js/integer_settings_advanced.js) that hooks the three toggle widgets. Turn one on and it clears the others; turn all of them off and it forces setting_1 back on, so the node can never sit at zero. The node's own docs state it plainly: only one output can be enabled at a time.

That split matters. If the JavaScript doesn't run - a headless/API job, a script that patches widget values, a workflow saved with two toggles already true - the two-frontend-minds-disagree scenario resolves by that priority order, silently. setting_3 wins over setting_2, which wins over setting_1, and nothing warns you.

Inputs and outputs

• setting_1 / setting_2 / setting_3 - required boolean widgets, labelled Enable / Disable. Defaults: setting_1 on, the other two off.
• setting_value - a single INT output, one of 1, 2, 3.

No inputs to wire, no second output.

Wiring it up

The output pairs directly with Switch (Three Way), and there's one step everyone forgets: selection_setting on that switch is a widget, so right-click it → Convert widget to input before you connect. Same story if you want to drive these toggles from a boolean node instead of clicking - convert them too, and remember the JS mutual-exclusion logic only watches widget callbacks, so a wired boolean bypasses the babysitter entirely. If you drive them programmatically, guarantee your own exclusion.

Installing it

Ships in ussoewwin/ComfyUI-NunchakuFluxLoraStacker, the pack that bundles a Nunchaku FLUX LoRA stacker, Florence-2 captioning nodes, a TensorRT CCSR upscaler and this ControlAltAI utility set. Manager: search ComfyUI-NunchakuFluxLoraStacker. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/ussoewwin/ComfyUI-NunchakuFluxLoraStacker.git
pip install -r requirements.txt

Restart. Nothing to download for this node, but install the whole requirements file anyway: the pack pulls its CCSR dependencies (pytorch-lightning, taming-transformers, omegaconf, einops, open-clip-torch) in at import time, and one missing package means the entire pack - every node - disappears from the menu. The nunchaku import is the guarded exception, so a machine that can't run Nunchaku still gets these nodes.

One naming note: this pack's version of these nodes is a Python 3.13-compatible fork of gseth/ControlAltAI-Nodes, which is why every class carries an hswq_ prefix. You can install both packs; you just can't share workflows between them by class name.

If something's off

Two toggles are lit at once. Either you loaded a workflow that was saved that way, or something set them from outside the frontend. The node will still answer - it just answers with the highest-numbered one - so the symptom is usually "my switch keeps choosing option 3 no matter what I untick." Click through all three toggles to re-sync the JS.

The switch ignores the value. 99% of the time selection_setting is still a widget and the wire never connected. Convert it to an input.

It resets to 1 by itself. That's the JS enforcing "always one enabled." If you wanted a genuine no-selection state, this node isn't the tool - you'd want a fallback switch instead.

Is it worth three widgets where you could just convert selection_setting to an input and type a number? Only if you want to flip branches while the graph runs and keep that choice visible on the canvas. That's a real convenience when you're A/B-ing two upscalers, and it's the reason the node exists.