List Contains Text Return String (Soze)

This is the "give me a value, not just true or false" sibling of the pack's Is Text In Text node. Both the display name - "List Contains Text Return String" - and the piped_text_list field name point at how it wants its data: as a pipe-delimited list (item1|item2|item3), not a free-form sentence. Feed it that list, a value to look for, and two fallback strings, and it acts as a tiny routing table.

How it works

It checks whether find_text matches an entry in piped_text_list, then outputs found_return_value if it did or not_found_return_value if it didn't. partial_match controls how strict that check is: off, find_text needs to match a list entry exactly; on, it just needs to appear as a substring within one of the entries - the same looser behavior as Is Text In Text. case_sensitive works the same way it does across this pack's other string nodes, off by default.

The inputs and output that matter

• find_text - the value you're looking for.
• piped_text_list - your candidate list, pipe-delimited.
• found_return_value / not_found_return_value - what gets returned in each case.
• case_sensitive, partial_match (both optional, off by default).

Output is a single STRING - whichever of the two return values applies.

Think of it as building a small lookup without an actual multi-branch switch: piped_text_list = "cat|dog|bird", find_text fed from wherever a user's subject came from, found_return_value = "animal_lora.safetensors", and you've got a one-node router swapping between two fixed strings based on a single substring test.

The real advantage over its Is Text In Text sibling is that you get a value back, not just a flag - so you skip the extra Switch node entirely for the common two-outcome case. If you need more than two outcomes (three or more possible LoRA files, say, depending on which of several subjects showed up), you'd chain a couple of these together or reach for something with real branching, but for the common "is this thing on my list, and if so what should I use" question, one node does the whole job.

Installing it

ComfyUI Manager: search ComfyUI_Soze. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/SozeInc/ComfyUI_Soze.git, pip install -r ComfyUI_Soze/requirements.txt, restart. Pure string handling, nothing else needed.

Common issues

The pipe character is your delimiter, so if any entry in your list contains a literal |, it'll get split apart as if it were two separate entries - build your list from data that won't contain pipes, or pre-process it with Multi Find And Replace to strip stray pipes before they reach this node.

Also double-check partial_match if a lookup that should hit is coming back as not_found_return_value instead. With it off, find_text has to equal a list entry exactly - a trailing space or a slightly different phrasing in your source data is enough to miss a match that looks correct at a glance. Turning partial_match on trades that precision for tolerance, which is usually the right call when the list entries are longer, freer-form text rather than single fixed tokens.