Number Slider

Here's a small thing that gets on my nerves every single time. A LoRA strength is a number between roughly 0 and 1, you change it constantly, and the control you get for it is a text field with a pair of tiny arrows. Tweaking a blend is a fiddly little operation you do forty times an hour.

A slider fixes that, as long as it remembers what range it lives in. That's this node.

What it is

One card, one row: a fat track on the left, the current value in the middle, a gear on the right. It opens at 0 to 1 in steps of 0.1 - precisely the range a LoRA strength or a weight wants - so a fresh node is useful before you've touched a setting.

It's the sibling of the pack's Number card (a typed number box) with one difference: the number is picked by dragging a track, and the range is yours. Two sliders are also deliberately the same size as the pack's boolean toggle, so a column of them lines up like someone meant it.

The inputs

Everything except the value itself lives in the gear menu at the right end of the card, which is a reasonable place for settings you touch once:

• kind - integer or float. Integer mode fixes the step at 1, drops the decimals, and rounds whatever was already there.
• value - the current number. Drag the track, or click the readout to type an exact value (Enter confirms, Esc cancels). Typed values get snapped to the step and clamped to the range just like dragged ones.
• min_value / max_value - the track's ends. Fill them in backwards and they get swapped rather than erroring; narrowing the range pulls the current value back inside it.
• step - how far one notch moves in decimal mode. 0.1 gives one decimal place, 0.01 gives two. Integer mode ignores it.

The output is a single value, and its socket is deliberately untyped (wildcard). That's not laziness: ComfyUI's socket types are fixed at the class level and can't change at runtime, so a node that outputs an int in one mode and a float in another has to declare a wildcard and let the actual returned value speak for itself. The upside is real - the same node feeds a FLOAT input like a LoRA strength and an INT input like steps or a seed, in either mode.

The arithmetic on the way out is more careful than it needs to be, which I appreciate: it clamps into the range, aligns to the step server-side (so an API call that posts 0.37 to a 0.1-step slider lands on the same number the UI would show rather than quietly disagreeing with the card), and rounds integers with floor(x + 0.5) instead of Python's round so it matches the frontend's Math.round. That last bit exists because round(0.5) is 0 in Python - which is how you end up with a card that reads 1 while the graph receives 0.

What to actually use it for

A LoRA strength fanned out to three loaders (change it once, all three follow - the classic primitive-node pattern). Steps in the 20–50 range with kind set to integer. Denoise at 0.01 steps when you're nudging an img2img pass. For anything where the two ends aren't the interesting part - a seed, a pixel dimension - a plain integer box is honestly fine and this is the wrong tool.

Installing it

Manager → Install Custom Nodes → ComfyUI-QG-tools, or:

cd ComfyUI/custom_nodes
git clone https://github.com/live1617/ComfyUI-QG-tools

Restart the app and look for QG-tools v0.9.7 | 38 nodes loaded | 8 categories. There is nothing to pip install - the pack's requirements file is comments only, by design, and this node loads no models. It's filed under QG-tools/Logic, which is a slightly odd home for a UI widget but a consistent one: it's a value node, not an image node.

Where people get burned

Don't "fix" the socket type. The output will look wrong to anyone used to typed nodes, and the temptation is to edit RETURN_TYPES to INT or FLOAT. Don't - the frontend validates connections against the declared type, so a mismatched socket silently refuses to connect. No error, no wire, and you spend an hour wondering why dragging does nothing.

Integer mode needs room for at least one integer. Set the range to 0.2–0.8 with kind on integer and there's no valid integer inside it, so the node falls back to the midpoint. Funny once.

A narrowed range silently clamps. If you set max to 0.8 and the value was 1.0, it becomes 0.8 - there's no warning. That's the correct behaviour, but it's worth knowing before you wonder why a LoRA got weaker after you tidied up the slider.

On the Nodes 2.0 question: this card is drawn on the canvas in the legacy renderer and swaps to a DOM card under Nodes 2.0, so it doesn't disappear when you turn the new frontend on - which is the exact break that took out some better-known packs' custom-drawn nodes. If you've been keeping Nodes 2.0 switched off because of one of those, this pack isn't the reason.