RM Positive Text Embed

The mirror image of RM Negative Text Embed, and they're meant to be used as a pair. Where the stock CLIP Text Encode (Positive Prompt) takes exactly one text input, this node takes two - a string_input for whatever's coming from another node (a styles file, a prompt list, another text node) and a text field for what you type in this run - and encodes the combination straight to positive conditioning. One less concatenation node, one less chance to mangle a comma.

How it works

Same mechanism as the negative twin: both text sources are trimmed, joined with ", ", tokenized through your CLIP, and encoded with encode_from_tokens_scheduled. If either side is empty it's simply skipped; if both are empty you get an empty positive, which is legal even if useless. The only hard error is a None clip, which raises a clear message. dynamicPrompts is enabled on the text field, so wildcard-style prompt syntax behaves as you'd expect.

The real reason these two nodes exist is workflow economy. In the RMAutomation world, the style system (see RM Styles Full) emits a positive string that changes every run - manual, random, or auto-incremented. This node lets that dynamic string flow in through string_input while you keep a hand-editable base in the text box, both landing in one CONDITIONING output. You get the automation and the manual control without building a merge node.

Inputs and outputs that matter

• clip (CLIP, required)
• text (STRING, multiline, required) - your manual positive.
• string_input (STRING, optional) - connect the Positive output of a styles node or any string source.
• Output: Positive (CONDITIONING) - straight into the KSampler's positive input.

How to install it

Ships in the RMAutomation pack:

cd ComfyUI/custom_nodes
git clone https://github.com/Moser9815/ComfyUI-RMAutomation

Restart ComfyUI; it's under RMAutomation/Text. No extra dependencies.

Common issues

The ordering convention is the one thing to internalize: string_input is prepended, your typed text appended. That's usually right - the dynamic source sets the subject, your box adds emphasis or fixes - but it's backwards if you expected the opposite. There's also a subtle weight-prompt consideration: leading tags carry structural weight, so if your styles string starts with quality tags and your manual text adds a subject, the effective ordering differs from a single hand-written prompt. If you ever see an empty positive, one of the two inputs was empty and the other was blank too - check the console or add a text display upstream to see what the string actually contained.