🔢 VRGDG Get Index Number

Long-running ComfyUI jobs have a quiet little problem: every run overwrites the last one unless you do something about filenames. You can set a seed, you can timestamp, but the classic answer is a counter - run 1, run 2, run 3 - and that counter needs to come from somewhere. VRGDG_GetIndexNumber is that somewhere: a trigger and a folder path in, a fresh index out.

How it works. You give it a folder_path and fire the trigger INT, and it hands back the next index INT. The idea, in practice, is that the node looks at what's already in that folder and returns the next number in the sequence - so each run gets its own slot and your outputs stop colliding. You then feed that index into your filenames, your seed math, or your prompt pickers. It's the pack's answer to the "don't clobber my previous render" problem, and it slots right next to the other index nodes (GetRunIndexFromJson, DisplayIndex) that this pack is built around.

The inputs. Two:

• trigger - an INT input that fires the calculation. Bump it (or wire it to something that changes per run) and the node re-runs.
• folder_path - the folder to derive the next number from.

The output. One INT, index. That's it - wire it into a SaveImage-style filename, an output directory, or a text picker's index, and you're done.

Where you'd use it. Think batch pipelines: you're rendering a bunch of scene variants, or the same prompt across several seeds, and you want each result named scene_<index>_<seed>. Without a counter you either overwrite or you stop and rename by hand. This node turns the "next number" into graph logic instead of a habit.

Installing. Part of the VRGameDevGirl pack:

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl

or install vrgamedev via ComfyUI Manager and restart.

Troubleshooting. The most common surprise is that an index derived from folder contents is only as good as the folder. Point it at a folder that isn't where your outputs actually land, and you'll get duplicates or skips without any visible error. Also, an index from this node is per-folder, not globally unique - if two workflows write to the same folder, they'll fight over numbers. And since trigger is an INT, a workflow that never changes it won't re-evaluate; give it a nudge between runs if the number looks stale. It's a simple node with one job: hand you the next number. Point it at the right folder and it does exactly that.