PettyPaintFakeConvert

ComfyUI's graph is strict about types: an any output won't always connect to a slot that demands a specific type, even when the value is actually fine. PettyPaintFakeConvert is a workaround for exactly that friction - it takes one wildcard value and puts it on six outputs, each labeled as a different type: INT, STRING, FLOAT, COMBO, SAMPLERS, and any. No conversion happens anywhere. Every output is literally the same value you put in. It's a type-label hack, and it's honest about it in the name.

When do you need this? The classic case is wiring a dynamic value into a slot whose type checker is stubborn. Say you have a text node or an exec result that's really a sampler name, and you want to feed it into a node that insists its input is one of the 34 SAMPLERS choices - ComfyUI refuses to connect a plain STRING there. Feed the value through FakeConvert's SAMPLERS output and the type checker sees what it wants, while the value stays a string underneath. Same trick for COMBO, INT, FLOAT - the output type label satisfies the graph, the runtime value satisfies the node. This is a pragmatic duct-tape pattern that shows up in power-user workflows that pipe config values around.

The inputs and outputs

• value - any type (*), the single source.
• Outputs: INT, STRING, FLOAT, COMBO, SAMPLERS (the full 34-sampler list, as a type), and any - all echoing value.

Installing it

It's in the petty-paint pack:

cd ComfyUI/custom_nodes
git clone https://github.com/mephisto83/petty-paint-comfyui-node

Restart ComfyUI, or install via ComfyUI Manager searching "petty-paint-comfyui-node". Declared dependency: Flask==2.1.2, unused here.

Common issues

The trap is in the word "convert": nothing is converted, and the downstream node will still receive whatever the original type was. If you shove a string through the INT output and feed it to a node that does real integer math, you'll get a runtime error that the label didn't protect you from - the hack only opens the connection, it doesn't change the data. So only use it when you know the value is already the right type and the type checker is the only obstacle. Also, its FUNCTION is named apply_lora_stack in the source - a copy-paste leftover from the LoRA node it was cloned from - which means any error traceback from this node looks confusing. The behavior is fine; the naming is just noise.