Playbook LoRA Select (External)

Playbook LoRA Select takes a LoRA name and outputs it as a string. That's the entire mechanism - but the interesting part is the metadata it carries, because this node is really about telling the Playbook3D cloud which LoRA your workflow expects.

For context: this is one of the "External" nodes in the Playbook Nodes pack, the ComfyUI side of Playbook3D's cloud 3D render service. When a workflow runs on their platform, the web UI can drive these nodes - you pick a LoRA in their interface, and the workflow sees the name. Locally, the node is a simple passthrough: whatever you type into default_value is what comes out of lora_name. You'd typically wire that output into a LoraLoader's name input, so the choice of style lives in one clean widget instead of buried inside a loader.

The inputs

• default_value - the LoRA name, an empty string by default. The author's tooltip just says "LoRA name." This is the value that gets output.
• base_model - a dropdown: SD1.5, SDXL, CogVideoX, or Flux. The tooltip asks "Which base model is this LoRA meant for?" - and that's the kicker, because it doesn't change the output at all. It's pure metadata, informing the Playbook3D platform (or the person reading the workflow) which model family the LoRA targets.
• id and label - the standard external-node binding metadata, inert locally.

Output is a single lora_name string, exactly equal to default_value. The base_model selection is not validated against it, doesn't filter anything, and doesn't appear in the output. If that feels anticlimactic, you're reading it right - the node is a structured way to declare "this workflow wants LoRA X, built for model Y," not a loader itself.

Install

Standard pack install: ComfyUI Manager → Playbook Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/playbook3d/playbook3d-comfyui-nodes

Restart ComfyUI. No API key, no network, no models - this node's whole job is threading a string through your graph. It won't even check that the LoRA name you typed exists on your disk; that check happens later, when a LoraLoader tries to actually load it.

Troubleshooting

There's almost nothing to break, but two things bite people. First: if the name doesn't match a LoRA you actually have installed, the node happily outputs it and your LoraLoader errors later - the failure shows up one node downstream, so when a loader complains about a missing LoRA, this is the first place to look. Second, if you're running on the Playbook3D cloud, base_model matters even though it's inert locally: pick the wrong family and the platform may offer you LoRAs that won't work with your checkpoint. Set it to match the model you're actually using and treat this node as the documentation it's designed to be.