FEEncLoraAutoLoaderStack

FEEncLoraAutoLoaderStack is the "let me apply this myself" version of FEEncLoraAutoLoader. Same prompt-tag parsing, same lora_autoinit_map.json automap support, same model-type dropdown - but instead of loading LoRAs into a model and clip directly, it outputs a lora_stack: a list of (lora_name, strength_model, strength_clip) tuples you can feed into a standard LoRA stack consumer.

That difference matters if your workflow routes LoRAs through something other than a plain loader chain - a stack-compatible LoraLoaderModelOnly, a batch loader, a node that reorders or filters stacks before applying. You get the convenience of tag-driven selection without committing to this pack's loading path. It's the right pick when the stack is a value you want to manipulate, not just apply.

The parse logic is identical to its sibling: <lora:name:weight> tags are extracted from the prompt, resolved against the loras folder, strengths read from the tag (one number = both, two = model:clip), and the cleaned prompt comes out the prompt output. Automap entries from models/loras/lora_autoinit_map.json are matched against the model_type dropdown and turned into stack entries keyed on trigger words.

The inputs

• model_type - sd1.5, sdxl, sd3, sd3.5, pony, il, noob, flux.
• prompt - the string with your <lora:...> tags (wired in, since it's force-input).
• strength_model / strength_clip - the defaults applied to tags without explicit strengths.

Outputs: lora_stack (LORA_STACK type), the cleaned prompt, and EXTRA (*).

A few honest notes. First, the LORA_STACK type isn't registered by this pack - it's a string the node declares, and it connects cleanly to other nodes that declare the same type string, but don't expect it to light up in every consumer's menu. Second, the silent-failure problem is inherited: tags that don't resolve to files just get skipped (the failed tags are flagged with ! in the output prompt). Third, because it doesn't apply anything, nothing about the model actually changes until a consumer applies the stack - if your workflow never applies it, you'll see zero effect and no error.

It's a slightly more advanced tool than the direct loader, and you'll know you want it when the answer to "where do my LoRAs go" is "into a stack I'm building elsewhere." For everyone else on a standard txt2img chain, the direct FEEncLoraAutoLoader is the simpler call.