LC LoRA Loader Stack ๐๏ธ
Build the LoRA list once, apply it to any model
- lora_stack
Here's the annoyance this node exists for. You're merging two checkpoints, or comparing a base against a finetune, and you want the same eight-LoRA recipe on both. With a loader-per-model setup you build the row list, then build it again, then keep them in sync by hand for the rest of the afternoon. LC LoRA Loader Stack breaks the loader in half: this node only builds the list, and a separate apply node sticks it onto whichever model/clip pair you point it at.
It's the Comfyroll pattern - CR LoRA Stack plus CR Apply LoRA Stack - done in this pack's own UI.
How it works
The face is exactly LC LoRA Loader's: enable checkbox, file dropdown with folder drill-down, strength, drag the โฎโฎ handle to reorder, โน Info button. Same JS file, same subfolder-grouped picker, same right-click Select all / Deselect all / Remove all.
The difference is underneath. This node has no sockets in at all - just one LORA_STACK out. Rows are serialized into a hidden lora_rows string as JSON, and on execution they're converted into a plain Python list of (lora_name, strength_model, strength_clip) tuples. Disabled rows, zero-strength rows and empty rows are dropped before the list is built, and the same strength goes into both the model and clip slot of each tuple.
That output shape matters more than it looks. LORA_STACK is a community convention, not a ComfyUI core type - it's the same list shape Comfyroll, Efficiency Nodes and Impact Pack's apply nodes expect. So this node is not locked to the rest of the pack; it will happily feed someone else's Apply LoRA Stack if that's what's already in your graph.
Inputs and outputs
Nothing to wire in. One output: lora_stack, which goes into LC Apply LoRA Stack (or a compatible apply node from another pack). That's the whole interface.
The reason to split it is reuse: one stack, several apply nodes, several model/clip pairs. Change a strength in one place and every branch follows.
Install
Manager โ ComfyUI LC123 Nodes, or:
cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC123_nodes.git
Restart. No pip install, no requirements.txt - the pack leans on torch/numpy/Pillow that ComfyUI already has. If the nodes don't appear, check you don't have a nested ComfyUI_LC123_nodes/ComfyUI_LC123_nodes/ folder; that's the single most common install mistake here. Do a hard browser refresh after updating the pack, since this node's whole face is JS.
Common issues
"I built the stack and nothing loaded." This node doesn't load anything - it only produces a list. If lora_stack isn't wired into an apply node, you have a very pretty no-op. That's the #1 confusion, and it's the design working as intended.
A row's LoRA silently doesn't apply. The file was moved or renamed after you saved the row, so the apply node skips it rather than exploding the graph. Re-pick the file. If the row is fine but the effect is missing, it's the architecture question - a LoRA trained on a different base will load and do nothing useful. Check the base model string on the Info popover.
Two apply nodes, doubled strength? Working as designed, and worth thinking about. Stacking the same LoRA twice in the list multiplies it, and running one stack through two apply nodes chained end-to-end compounds the effect. If the second model looks overcooked versus the first, that's your recipe, not a bug - drop per-row strength.
Can I feed it a stack built in another pack? Yes on the apply side (that's the convention above), but the reverse doesn't work: this node takes rows, not a LORA_STACK input. If you need to merge two lists, you'd need a stack-merge node, which this pack doesn't ship.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_rowsopt | STRING | [] | Internal: the row list (on/lora/strength), maintained by the node's own face. Not meant to be typed by hand. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| lora_stack | LORA_STACK | โ |