ImpactWildcardEncode
Wildcards, inline LoRAs, and CLIP encoding in one node
- model
- clip
- model
- clip
- conditioning
- populated_text
ImpactWildcardEncode is the wildcard processor with two extra jobs folded in: it loads LoRAs written inline in the prompt, and it encodes the result to conditioning. So instead of chaining a wildcard node, a stack of LoRA loaders, and a CLIP Text Encode, you write one prompt with __wildcards__ and <lora:name:0.8> tags in it, and this single node resolves the wildcards, applies the LoRAs to the model, and hands you back the encoded conditioning. It's a genuine convenience node - three steps collapsed into one.
The headline feature is the inline LoRA syntax. Write <lora:add_detail:0.7:1.2> in your prompt and the node loads that LoRA at those strengths, no separate loader node required. If you've used A1111's prompt-embedded LoRA tags, it's the same idea. That said, if LoRA management is your main need, rgthree's Power Lora Loader is the community's go-to for stacking and toggling many LoRAs with trigger-word lookups - this node's strength is specifically the combination of wildcards, inline LoRAs, and encoding in one box.
How it works
The node runs the same wildcard resolution as ImpactWildcardProcessor (__wildcard__ files and {a|b|c} choices, with the same populate/fixed/reproduce modes), then parses any <lora:...> tags out of the populated text and applies each LoRA to the incoming model and clip. Once every LoRA is loaded, it encodes the final prompt with that modified CLIP into conditioning. The order matters - LoRAs load before the encode - which is why the node needs model and clip as inputs and returns modified versions of both alongside the conditioning.
The inputs and outputs that matter
model,clip(required) - the checkpoint's model and CLIP. The node returns modified copies with the LoRAs applied.wildcard_text(required) - your prompt, with__wildcards__,{a|b|c}, and<lora:name:strength>tags mixed in freely.populated_text(required) - the resolved prompt, shown before execution and saved with the workflow.mode-populatererolls wildcards each run,fixedfreezes the populated text,reproducerebuilds from seed. Same behavior (and same common confusion) as the standalone processor.seed- drives the wildcard randomness.
Two helper dropdowns, "Select to add LoRA" and "Select to add Wildcard," insert available LoRA and wildcard names into your text. Outputs: model and clip (with LoRAs applied - wire these onward to your sampler, not the raw checkpoint outputs), conditioning (the encoded positive prompt), and populated_text.
How to install it
Install the pack via ComfyUI Manager (search ComfyUI Impact Pack, install, restart), or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack comfyui-impact-pack
cd comfyui-impact-pack
python -m pip install -r requirements.txt # ComfyUI's python; python_embeded on portable
then restart. LoRAs load from your normal ComfyUI/models/loras folder - the tag name matches the filename. Wildcards live in ComfyUI-Impact-Pack/wildcards (or custom_wildcards). If you also install the Inspire Pack, you unlock Lora Block Weight (LBW=...) syntax inside the LoRA tag for per-block strength control.
Common issues & troubleshooting
My LoRA didn't apply. The single most common cause: you wired the checkpoint's model/clip straight to the sampler and ignored this node's model/clip outputs. The LoRA lives on the outputs - route those forward, not the originals. Second cause: the tag name doesn't match a file in models/loras.
The prompt won't reroll. You're in fixed mode, which freezes populated_text on purpose. Switch to populate. (And if you're feeding seed from an input, the node's own tip is to write directly into populated_text with mode: fixed so the seed doesn't reroll the wildcards.)
<lora:...> showed up in my image metadata as literal text. That's expected - the tag is parsed out of the populated text, so make sure the LoRA syntax is in the text that actually runs (the populated box in fixed mode, or the wildcard box in populate mode). If it appears in the populated output verbatim and didn't load, recheck the filename and strength format <lora:name:model_strength:clip_strength>.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| wildcard_text | STRING | Enter a prompt using wildcard syntax. | |
| populated_text | STRING | The actual value passed during the execution of 'ImpactWildcardEncode' is what is shown here. The behavior varies slightly depending on the mode. Wildcard syntax can also be used in 'populated_text'. | |
| mode | COMBO | populate: Before running the workflow, it overwrites the existing value of 'populated_text' with the prompt processed from 'wildcard_text'. In this mode, 'populated_text' cannot be edited. fixed: Ignores wildcard_text and keeps 'populated_text' as is. You can edit 'populated_text' in this mode .reproduce: This mode operates as 'fixed' mode only once for reproduction, and then it switches to 'populate' mode. | |
| Select to add LoRA | COMBO | 1 options: Select the LoRA to add to the text | |
| Select to add Wildcard | COMBO | 1 options: Select the Wildcard to add to the text | |
| seed | INT | 00–18446744073709550000 | Determines the random seed to be used for wildcard processing. |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |
| conditioning | CONDITIONING | — |
| populated_text | STRING | — |