Reset Counter (to file) v1.2.1

This is the other half of a two-node counter system, and it does exactly one thing: it sets the counter back to zero. If you've ever watched a batch loop run 400 images too far because you couldn't be bothered to go find the state file, you already know why this exists.

How the counter system works

The pack's Counter (from file) node keeps a file called loops.json in your ComfyUI output folder. Every time the workflow runs, it reads the number, hands it to you as loop_count, and writes count + 1 back for next time. That number is usually wired into the image_index of a batch image loader to step through a dataset.

ResetCounterFile is the panic button for that loop. It has a single trigger_reset boolean (defaults to True, and the button is literally labeled RESET), and when it executes it rewrites loops.json to contain 0. No outputs, no return value - it's an output-only utility node you drop into the graph, run, and are done with.

What a beginner actually does

Drop it on the canvas, click the toggle so it runs, queue once, and the counter file is back to zero. The classic use is a dataset captioning or batch-render job where you don't want to babysit the filesystem: run your loop, let it fly, then reset and start over without opening a text editor.

The gotcha that bites

This node writes 0 to the file every time it executes - the boolean is a trigger, not a guard. Leave it connected in a workflow you keep running and it will clobber the counter on every queue. The intended rhythm is: reset → run → bypass or remove the node → let the counter climb again. People who leave it wired in and then wonder why their loop never advances have found this the hard way.

One more thing to know: the counter file lives in the shared output folder, so this counter state is global to your ComfyUI install, not per-workflow. If you run two different loops with the same loops.json, they'll fight over it. That's not a bug in this node - it's how the whole counter system is designed - but it's worth knowing before you run two batch jobs in parallel and watch them stomp each other's counts.