[SSN] Convert Int To Others

[SSN] Convert Int To Others takes one integer and hands you back the string form and the float form. 42 in, "42" and 42.0 out. That's the entire node, and I don't mean that dismissively - it's the rare converter that cannot go wrong.

You reach for it when ComfyUI's strict type system gets between you and what you want to build. A filename saver wants to glue your step count into a file name - that's a string, and an INT won't coerce. A sampler or a scale node wants a float where you've got an integer from a widget. In a graph that mixes types across the plumbing layer, these little shims are the duct tape that keeps everything connected. The plumbing doc that maps this layer frames it exactly right: most of a ComfyUI workflow is this kind of unglamorous data-flow glue, not pixels.

The two outputs are named string and float, both fed from the single integer input (a standard INT widget with a 32-bit range and step 1). Nothing is computed beyond Python's built-in str() and float(), so there are no edge cases to trip on - no truncation ambiguity, no rounding surprises, no negative-number weirdness. -7 becomes "-7" and -7.0, as expected.

The honest positioning: you almost certainly already have another way to do this - most node packs and even core ComfyUI can convert via their own utilities, and you can always hand-wire values. This node's selling point is that it's in the same pack as the rest of the smn_support_nodes set, so a workflow built around the pack can convert in place without importing a second toolkit just for one cast. It's also the kind of thing that's useful to beginners precisely because it's dead simple: wire, convert, done, no settings to misread.

Install

Part of smn_support_nodes by SummonTheCat. ComfyUI Manager → search smn_support_nodes → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/SummonTheCat/smn_support_nodes

Restart required. Dependencies (opencv-python, imageio-ffmpeg) auto-install; no models to download.

Troubleshooting

There's genuinely almost nothing to troubleshoot here - the node can't fail on its input since any integer converts cleanly. The only real-world annoyance is the same one that hits all thin converters: if you wire the float output somewhere and later change the source to a fractional number, you'll need a float-input node instead, because this one only accepts integers at the socket. If you find yourself needing string, truncated-int, and rounded-int all at once, that's SsnConvFloat's job.