Trigger (GeN13)

Trigger (GeN13) is a button, and a wire. Press it, and the integer coming out of it becomes a different integer. That's it. Its entire reason to exist is that Counter (GeN13) - its sibling in the same pack - resets itself whenever the value on its reset input changes, so if you want your counting sequence to start over from the top, you need something that changes a value on demand. This node is that something.

It's narrow, and honestly the most honest way to describe it is as half of a pair. But it's a genuinely useful pair. If you run a batch of 20 prompts through a Counter driving a Text Switch, then decide you want to run the second half of that batch again, you press TRIGGER and every counter wired to it is back at its start value on the next queue. One button, whole graph, no right-clicking counters and resetting them one by one.

How it works

There are two ways the output changes, and the code adds them together. The first is pulse - an integer from 0 to 2,000,000,000 - which the node's big TRIGGER button increments by one each press. The front end draws that button and keeps the armed value in the node's properties, so it survives an F5 refresh mid-press.

The second is the optional input, which accepts anything (*) - typically a boolean switch, or some other value that flips. Every time that upstream value differs from the last value the node saw, the trigger fires. The first connection only records the value; it doesn't fire, so attaching a wire doesn't spuriously reset everything you're counting.

The output is simply pulse plus the number of upstream changes it's seen, keyed per workflow and node so two workflows that both happen to have a node #5 don't share a counter. No trigger means no change, which is the property that matters: the downstream Counter sees the same number, so it just keeps counting normally.

The status line under the button tells you where you are - READY, then ARMED · NEXT RUN RESETS from the press until a run with that pulse has executed, then TRIGGERED BY INPUT for two seconds when the input changed. That ARMED state is the thing to watch: pressing the button doesn't reach into the graph and reset anything immediately. The new value arrives at Counter when you next queue, and Counter returns to its start value then.

The inputs and outputs

• pulse - the INT the button bumps. Leave it at 0 and just press the button. (Setting it from the API to a new number counts as a trigger too, which is how you'd script it.)
• input - optional, any type. Fires once per change of the upstream value.

One output, INT, and there's essentially one place it goes: the reset input of a Counter (GeN13). Because that reset takes any type and only reacts to a change, a Trigger is only meaningful wired into something that watches for changes.

Install

Manager: search GeN13, install, restart. Or manually:

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

The pip line installs one package, nvidia-ml-py, for the pack's GPU monitor strip beside the Run button - this node doesn't need it. What it does need is the pack's web/ folder: the TRIGGER button and status line are JavaScript. Install the whole pack rather than copying .py files out of nodes/, or a bare Trigger class is just an integer box you'd edit by hand.

The pack is small and new - GPL-3.0, © GeN's Studio Inc., no community threads mentioning it at all - so there's no troubleshooting folklore to lean on. Every node's name ends in (GeN13); double-click the canvas and type GeN13 to see them all.

Where it bites

The state is in memory. The change count resets when you restart ComfyUI, which only affects the absolute value coming out of the node, not whether it changed - so your Counter still behaves. But it does mean the number is not a stable record of anything; don't try to use it as one.

A prompt submitted through the API has no workflow attached, so the state key falls back to the node id alone. Two scripts both driving node "5" would share the same change count. Rare, but exactly the kind of thing that produces one confusing evening.

And the obvious one: an input wired to something that changes every single run means the trigger fires every run, and your counters never get past their first value. That's a legitimate setup - looping prompt #1 forever - but if your sequence is stuck, look at the input before you blame the Counter.