ImpactInt

ImpactInt is exactly what it looks like: a box that holds one integer and hands it out. You type a whole number, it outputs that whole number. There is no hidden cleverness here, and if you were expecting some, that's the whole article - go wire it up.

The interesting question is why Impact Pack bothers to ship an integer node when ComfyUI has a "Primitive" node and half a dozen other packs offer the same thing. The answer is that ImpactInt lives in Impact Pack's experimental Logic category, and it's there to be the counter in a loop. If you're building one of the pack's auto-queuing loops - the kind where the graph re-queues itself over and over - you need a value that survives across iterations and can be read, compared, and rewritten. ImpactInt is that value's home. It pairs with ImpactCompare (which asks "has the counter passed the limit yet?"), ImpactConditionalBranch (which picks a path based on the answer), and Set Widget Value (which bumps the counter for the next pass). On its own it's a number. In that company it's a loop variable.

The one input, the one output

value is an INT, defaulting to 0, and the range runs from 0 up into the billions, which is more headroom than any real workflow needs. The output is named INT and it's that same number, typed as an integer so ComfyUI's connection checker will only let you plug it into sockets that actually want an int - a step count, a seed, a batch size, a width or height field you've converted to an input.

That type discipline is the practical reason to use a dedicated int node instead of a generic primitive: fewer "mismatched type" surprises when you drag the noodle. If you convert a widget like steps or seed to an input and want to drive it from one central knob, ImpactInt is a clean source for it.

When to actually reach for it

Two honest cases. First, the loop case above - you're genuinely building iteration with Impact's logic nodes and you need a counter. Second, the plumbing case: you want a single integer defined in one place and fanned out to several nodes, so you change it once instead of in five widgets. That's a real quality-of-life win in a big graph.

Outside those, don't overthink it. There is nothing to tune, nothing to break, and no performance cost - it doesn't touch the model or the GPU. It's a constant. The only "gotcha" worth naming is expectation management: people sometimes assume a node in a pack this large must do something, and go hunting for a setting that isn't there. It isn't there. It's an integer.

One thing to keep straight if you're loop-building: ImpactInt holds a value you set, but it doesn't increment itself. Advancing the counter between iterations is a separate step, done with Set Widget Value writing back into this node's widget at the end of each pass. The loop nodes are the niche end of Impact Pack - plenty of people run FaceDetailer for years and never touch them - so if this is your first time down here, budget a little patience.

Installing it

ImpactInt ships inside ComfyUI Impact Pack, so you get it by installing the pack. The clean way: ComfyUI-Manager → search ComfyUI Impact Pack → Install → restart. By hand: cd ComfyUI/custom_nodes && git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack, then install the pack's requirements.txt into the same Python environment ComfyUI uses (portable build: ..\..\..\python_embeded\python.exe -m pip install -r requirements.txt), and restart. Since v7.6 the pack no longer auto-installs its dependencies, so a manual clone without the requirements step just fails to load. Impact Pack is ltdrdata's - the same person who maintains ComfyUI-Manager - which is why it's one of the most trusted node packs around. ImpactInt itself pulls in no models and no heavy libraries; if the pack loads at all, this node works.