ImpactCompare

ImpactCompare takes two values, compares them the way you choose, and outputs true or false. Is a greater than b? Equal? Not equal? Pick the operator, feed the two values, get a boolean. It's a comparison operator drawn as a node, and it's the piece that turns Impact Pack's experimental logic nodes from "a pile of parts" into actual control flow.

On its own it's not much. Its whole reason to exist is to produce the boolean that something else branches on. In ComfyUI there's no native "if," so Impact Pack fakes control flow with a small kit of nodes, and ImpactCompare is the test in that kit. The canonical use: you're running one of the pack's auto-queuing loops, an ImpactInt holds a counter, and you compare it against a limit each pass - "counter < max?" The true/false that comes out feeds an ImpactConditionalBranch, which decides whether the loop keeps going or wraps up. Counter, compare, branch: that trio is how you build iteration in a graph that has none.

The inputs and the one output

Three inputs:

• cmp - the comparison, an enum: a = b, a <> b (not equal), a > b, a < b, a >= b, a <= b, plus tt (always true) and ff (always false). The tt/ff options look pointless until you want a branch pinned to a constant for testing.
• a and b - the two values to compare, both wildcard-typed (*). Numbers are the obvious case, but because they're wildcard you can compare other comparable values too.

The single output is a BOOLEAN. Wire it into an ImpactConditionalBranch, a Set Mute State, or anything that gates on true/false.

Where it fits, honestly

This is niche-of-the-niche. Most people who install Impact Pack do it for FaceDetailer and never once open the Logic category. ImpactCompare only matters if you're the sort who's automating a multi-pass loop - re-queuing the workflow, ticking a counter, stopping when a condition is met. In that world it's essential; outside it, you'll never miss it. There's no bundled step-by-step example either, since the loop nodes are the least-documented corner of the pack, so expect to prototype the counter-compare-branch pattern a couple of times before it feels natural.

If you are building loops: the community pattern these plug into is the pack's Queue Trigger, which re-adds the prompt to the queue when it receives a signal. ImpactCompare is what tells the loop when to stop signalling.

Common issues

The one to watch is comparing values that aren't cleanly comparable. The wildcard typing is generous - it'll let you wire almost anything into a and b - but "is this image greater than that image?" is nonsense, and you'll get a meaningless boolean or an error. Keep a and b to things that have a real ordering (numbers, most of the time). For a loop counter that's automatic, since you're comparing an int against an int.

The other thing is the usual Impact-Pack wildcard caveat: because so many of these nodes use the * type that ComfyUI doesn't fully support yet, you can occasionally get spurious type-validation warnings even when the wiring is correct. If the graph runs and the boolean makes sense, a red type message on a wildcard socket is often just that limitation talking, not a real fault.

Installing it

ImpactCompare ships with ComfyUI Impact Pack, so install the pack to get it. Easiest: ComfyUI-Manager → search ComfyUI Impact Pack → Install → restart. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack, then install its requirements.txt into ComfyUI's Python environment (portable build: ..\..\..\python_embeded\python.exe -m pip install -r requirements.txt), and restart. Since v7.6 there's no auto-install of dependencies, so a manual clone that skips the requirements step won't load. Impact Pack is ltdrdata's - the ComfyUI-Manager and Inspire Pack maintainer - which is why it's one of the most trusted packs going. ImpactCompare itself needs no models and no heavy libraries; if the pack loads, it works.