StringToInteger (Badman)

Small, boring, and useful in exactly the way small boring nodes are: it parses a STRING into an INT. That sounds trivial until you're working with something that outputs numbers as text - a value pulled out of a filename, an index parsed from a prompt-file entry, a number typed into a string field on another node - and you need it as an actual integer to feed a widget that only accepts INT, like a seed, a width, or a batch count.

How it works

There's no cleverness to explain: it takes whatever text is in value and parses it as an integer, then outputs that integer. The pack's README describes it plainly as parsing "a string into an integer for use with numeric inputs" - that's the whole job. It's the connective tissue for graphs where a string-producing node (a Concat String, a filename, a wildcard result) needs to feed an int-typed slot on something else.

The inputs and outputs that matter

• value - a plain STRING field. Whatever text you put here (or wire in from another string output) gets parsed into a number.

Output: INT - the parsed integer, ready to plug into any numeric input.

One thing worth knowing about this node specifically: its schema marks it as an output node, which in ComfyUI means it always runs when the workflow executes, even if nothing downstream is wired to its output. Most simple pass-through utility nodes get silently skipped if unused; this one won't be - harmless, but worth knowing if you're wondering why it's still firing in a graph where you thought you'd disconnected it.

How to install it

Search ComfyUI-BadmanNodes in ComfyUI Manager, or install it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/MariusKM/ComfyUI-BadmanNodes

Restart ComfyUI. No models, no extra dependencies for this one - it's pure Python string parsing, part of the same small personal utility collection as the pack's other string and number helpers.

Common issues & troubleshooting

The string isn't actually an integer. This is the failure mode that matters. A value has to look like a whole number for the parse to succeed - something like "5.0" (a decimal, not an integer), "five", or a value with stray whitespace or units baked in ("5px") will not parse cleanly. If your workflow errors out at this node, print or preview the string going into value first and check it's a bare number, no extra characters.

You're feeding it something meant to stay a float. If the number genuinely needs a decimal point - a strength value, a blend weight - this is the wrong node. It converts to an integer specifically; anything that needs fractional precision will get truncated or fail to parse.

It's always executing and you don't want it to. That's the is_output_node behavior above, not a bug. If you need it to sit dormant unless actually used, that's not something you control from this node - restructure the graph so it's only present on paths you actually want evaluated.