Float Variable [🅝-🅢🅤🅘🅣🅔]

Functionally identical to this pack's plain Float Variable - same single value input, same FLOAT output, same one job. The only difference is the circled [N-SUITE] badge in the node name, which is what the pack switched every node to after its February 2024 rewrite (done specifically to avoid class-name collisions with other packs). If you're setting up a fresh workflow, this is the version you'll actually find in a current node search.

Why it exists

Straight from the README: ComfyUI's built-in Primitive node can't link certain matched widgets together - you can't wire start_at_step on one KSampler to steps on another, even though you'd often want them to agree. Rather than solve that generally, Nuked88 built the smallest possible fix: a node that holds one float value and exposes it as an output. Wire that single output to every place that needs the same number, and you've got one source of truth instead of two widgets you have to update in lockstep by hand.

The input and output

value - a float, defaulting to 0, set once on this node's widget. FLOAT - the output, fanned out to however many places need it. There's no computation involved; it's a value holder, not a calculator. If you've come from rgthree-comfy's Power Puter or Context nodes, this is a much narrower tool solving one specific version of the same general problem - keeping a graph's plumbing manageable - rather than a general-purpose expression evaluator.

Installing the pack

• ComfyUI Manager - search "ComfyUI-N-Nodes," install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/Nuked88/ComfyUI-N-Nodes.git, then restart ComfyUI.

No models or extra dependencies for this one - it's one of the lightest nodes in the whole pack.

Common issues & troubleshooting

You're not sure you even need it. Try linking the two widgets you care about directly first. This node only earns its place in the specific situations ComfyUI's own Primitive can't reach - matched settings across two separate samplers being the canonical example from the pack's own docs.

A change here doesn't seem to be reaching one of the places you expected. The usual culprit is one of the two intended consumers still being wired to its own local widget instead of this node's output - double-check both connections rather than assuming the node itself is misbehaving.

Looking for the exact same idea with an integer or a string. This pack has Integer Variable [n-suite]-style equivalents and String Variable [n-suite] for that - same pattern, different type per node, no single generic variable node.