BigPlayer LoRA State
Point the LLM at your LoRAs, in LoRA Manager syntax, without applying a thing
- preset_config
- lora_syntax_also
- lora_stack
- preset_config
BigPlayer LoRA State is the LoRA half of the pack's state-indication trio. It exists to tell the LLM which LoRAs are in play so the prompt it writes actually targets them. It does not apply LoRAs - that's still your Lora Loader's job, usually via ComfyUI-Lora-Manager - and it doesn't merge anything. It turns what you tell it into context the root can hand to the model.
The inputs that matter
lora_syntax- the main field. Multiline, and it expects LoRA Manager syntax:<lora:name:0.6>or<lora:name:0.6:0.4>(model strength, then optional clip strength). That's the same tag syntax Lora Manager uses, so if you already speak it, you're home.lora_syntax_also(optional) - takes a string or a list of strings from another node and concatenates it ontolora_syntax. Handy when the list comes from a wildcard or a text input elsewhere in the graph.lora_stack(optional) - link aLORA_STACKfrom ComfyUI-Lora-Manager directly, and the node reads the entries (name, model strength, clip strength) from the stack instead of you retyping them.
The output is a single preset_config, chaining into other state nodes and finally into the root's optional preset_config.
The mechanism, and where it's strict
The syntax parsing is a hard regex: it accepts only LoRA Manager tags, and anything else - stray parentheses, bare filenames, random text - raises a clear "invalid LoRA syntax" error rather than silently dropping it. That's deliberate: the README's reliability goals are "fail clearly and predictably," and this node is one of the strictest about it. Entries are deduplicated case-insensitively, and when two sources list the same LoRA, the linked one wins.
When the root renders the preset, the LLM sees something like:
- LoRAs:
- <lora:furry_fox_v2:0.6>
and the prompt fragments tell it to craft output "tuned for the chosen setup," including LoRA-specific considerations in its comments. That's the difference between an LLM vaguely mentioning a style and an LLM aiming at the style your loaded LoRA actually produces.
The honest position
This is context-only, and it's meant to be. The pack's own roadmap puts LoRA recommendation and application nodes in Phase 2 - this node is the phase-one "let the LLM know what's loaded" step. Don't come here expecting it to stack LoRAs; come here expecting your prompts to stop ignoring them.
Install and troubleshooting
Pack install: ComfyUI Manager, search "BigPlayer Prompting", or git clone https://github.com/josh-ent/comfyui-bigplayer-llm-nodes into ComfyUI/custom_nodes, then restart. Deps are httpx and pydantic; no model downloads. The most common stumble is typing LoRA names with commas or bare filenames instead of <lora:name:strength> tags - the node will tell you exactly that.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_syntax | STRING | Use LoRA Manager syntax like <lora:name:0.6> or <lora:name:0.6:0.4>. | |
| preset_configopt | BIGPLAYER_PRESET_CONFIG | Optional preset config emitted by another BigPlayer state-indication node. | |
| lora_syntax_alsoopt | * | Takes a string or list of strings and concatenates it onto `lora_syntax`; linked entries win ties where needed. | |
| lora_stackopt | LORA_STACK | Optional linked LORA_STACK compatible with ComfyUI-Lora-Manager. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| preset_config | BIGPLAYER_PRESET_CONFIG | — |