📝 Wildcard Processor Advanced

Same wildcard engine as the plain Wildcard Processor from this pack - __file__ lookups, {a|b|c} inline choices, weighted picks, multi-select, ranges, variables, all of it - but this version splits its work open instead of handing you one finished string. If the regular node is for "just resolve my prompt," the Advanced version is for "resolve my prompt, and also tell me exactly what got picked." That second thing matters more than it sounds like: once you're randomizing outfits, colors, or styles across a batch, knowing which combination produced the good image is half the value.

What the extra outputs buy you

Everything about the wildcard syntax itself is identical to the base node - file wildcards, inline {a|b|c} choices, {5::a|b|c} weighted picks, {2$$...} / {1-3$$...} multi-select, and ${var=...} variables all work the same way here. What's different is what comes out the other side. Where the base node gives you one processed_text string, this one gives you six outputs, and the useful pair is extracted_tags_string / extracted_tags_list - just the resolved values of every wildcard and choice block, stripped of the surrounding prompt text, joined by | in the string form. So if your template is a photo of a {red|green|blue} car, __style__ and it rolls green and impressionist, processed_text gives you the full sentence, while extracted_tags_string gives you green|impressionist - the two things that actually varied. Pair that with a text-save node or bake it into a filename and you've got a lightweight log of what every batch member actually rolled, without parsing the sentence back apart yourself.

raw_tags_string / raw_tags_list are the unprocessed counterpart - the tag blocks themselves, delimiters included, before resolution. That's more of a debugging tool: useful if a wildcard block isn't resolving the way you expect and you want to confirm the parser saw what you think it saw.

The seed output just echoes the seed that was actually used - handy for wiring into a metadata-saving node, or into a second node downstream that needs to reproduce the exact same roll instead of you re-typing the number.

One honest caveat, straight from the schema: despite the "list" naming, extracted_tags_list and raw_tags_list are typed as single STRING outputs, not ComfyUI's native list type - so they're joined text, not something that fans out into separate node executions. If a downstream node needs the individual items split apart, run it once and check the raw output first.

Inputs

Three carry over unchanged from the base node - wildcard_string (your template), seed (drives the randomness, reproducible with the same string), recache_wildcards (force a reload of wildcard files from disk, toggle back off once it's picked up your edit). The one addition is multiple_separator (default a single space) - the join text used when a {2$$...} block pulls multiple items and doesn't specify its own separator inline. Set it once here instead of writing {1-3$$, $$...} every time you want commas.

Installing it

Same pack as everything else here - search ComfyUI-mnemic-nodes in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/MNeMoNiCuZ/ComfyUI-mnemic-nodes

Restart ComfyUI. Nothing extra to configure for this node specifically - the pack's .env setup step is only needed if you're using the separate Groq LLM/VLM/audio nodes elsewhere in the same pack.

Where people get stuck

Six outputs and only using one. If you don't need the tag-extraction outputs, just leave them unwired - ComfyUI doesn't force you to consume every output socket. Reach for this node over the plain Wildcard Processor specifically when you need to know what was picked, not just get the resolved prompt.

multiple_separator doesn't seem to apply. Check whether your {...$$...} block set its own separator inline ({1-3$$, $$...}) - the inline form takes priority over this node-level default, same as any per-instance override beats a global default.

Everything else is the same troubleshooting as the base node. A wildcard resolving literally in the output means the file's missing or misnamed in the wildcard folder; weighted picks are relative to the block's weight sum, not literal percentages; and a seed that won't budge between runs is almost always ComfyUI's auto-added randomize/fixed control sitting on fixed.