HB Wildcard Processor

HB Wildcard Processor is the workhorse of this pack - the one node that does more than shuffle strings. It takes a prompt full of wildcard placeholders and rolls them out into an actual prompt, using two different syntax families at once: inline {a|b|c} brackets and file-based __name__ wildcards that pull random lines from text files. The output is a ready-to-use prompt plus a second output that reports which wildcards fired. For anyone who batches prompts for variety, it's the difference between writing twenty prompts and writing one.

Two syntaxes, one node

The inline bracket syntax is the old Automatic1111 trick that prompt-engineering guides still teach: {brown|blonde|black} hair picks one option per run. This node upgrades it with weights - {3::Red|1::Blue|Green} picks Red three times as often - and with full nesting, so {2::{1::fast|slow}|{2::red|blue}} resolves recursively. Same family as the "batch 32 and get the same person across different moods" trick from the old days; most people who arrived after 2024 never learned this syntax existed.

Then there's the file side, which is the real feature. __colors__ loads a random line from wildcards/colors.txt, and __hair/long__ goes into a subfolder. The syntax layer on top is where this node earns its keep:

• __!places__ - lock: repeated occurrences reuse the same pick
• __+places__ / __-places__ - shift the selection offset forward or back
• __*places__ - force a fresh random pick
• __2$$places__ - pull two lines instead of one
• __places|Green__ - filter: only pick lines containing "Green"

Deterministic per seed (input, default 42), so the same seed reproduces the same roll - that's your reproducibility for free. If it can't find a file, it leaves the __name__ token in place silently, which is the debugging trap: an unfound wildcard looks like a typo'd prompt, not an error.

Where the wildcards live

This is the part that trips people up, because it's not the usual location. The node reads from ComfyUI/user/wildcards/ first, with a fallback to ComfyUI/wildcards/. So:

cd ComfyUI/user
mkdir -p wildcards
# then drop .txt files in there, one option per line:
echo "red" >> wildcards/colors.txt
echo "blue" >> wildcards/colors.txt

Each line is an option, and lines written as [Title] content get their [Title] extracted into the report output - so you can see which wildcard chose what at a glance. It's a genuinely useful debugging output, not a gimmick. The repo also ships an example workflow in /examples.

Notes and honest caveats

The seed behavior is a little split-brained: bracket wildcards use a dedicated random.Random(seed), while the file wildcards call random.seed(seed) on the global RNG. Practically that means bracket picks and file picks each change with the seed but don't interfere with each other - don't try to reason about it beyond "same seed, same result." The category still reads JN_Party because this is a rebrand of the old JN wildcard processor (the source header still says "JN_Wildcard Processor v1.5"). It works exactly as the JN family did, just under the HB name.

Install

Part of HB ComfyUI Nodes (HassanEclipse/comfyui-hb-party), no dependencies and no model downloads. ComfyUI Manager:

Manager → Install via Git URL → https://github.com/HassanEclipse/comfyui-hb-party

or:

cd ComfyUI/custom_nodes
git clone https://github.com/HassanEclipse/comfyui-hb-party comfyui_HB_Party

Restart, create your wildcards folder, and you're rolling.

Bottom line

If you batch generations or build character-libraries from a single template, this node is the real deal - weighted inline choices plus a proper file-wildcard system in one box, with a report output that tells you what happened. It's not famous, and it won't be, but for prompt-variety workflows it does the job without ceremony.