String to Integer

This is the most boring node in the whole pack, and it's also one of the ones you'll actually end up using. String to Integer does exactly one thing: it takes a STRING and hands you an INT. Why would you ever need that? Because when you drive ComfyUI from a script or an API request, the values that should be integers keep arriving as text.

Here's the scenario. You're calling ComfyUI's /prompt endpoint with a JSON payload, and your script sends "seed": "42" - a string, because JSON from a form or another language didn't know it should be a number. The seed socket wants an INT. The graph dies. Or you're using this pack's own RequestInputs node to feed parameters in from a request body, and it hands values over as strings because that's what text fields are. String to Integer is the adapter that fixes the mismatch.

Under the hood it's a single Python call: int(inStr). That's the whole mechanism - no image processing, no model, nothing to download. It lives under Bmad/api/parseInput alongside its siblings String to Float and Input/String to Int Array, which exist for the same reason: parse the text, hand the graph a properly-typed value.

The inputs that matter

• inStr - the string you want converted. Default is empty, so if you run it unconnected you'll get a hard error; wire it up first.

The single output, INT, plugs into any integer socket: a seed, a step count, a batch size, whatever.

Install

String to Integer ships in bmad4ever/comfyui_bmad_nodes, a grab-bag pack of API helpers, OpenCV masking nodes and general utilities. Install it once and you get all twenty-ish of its nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_bmad_nodes
cd comfyui_bmad_nodes
pip install -r requirements.txt

Then restart ComfyUI. Easier path: ComfyUI Manager → "Install Custom Nodes" → search comfyui_bmad_nodes → Install, and let Manager handle the dependencies (it pins opencv-python~=4.8, so that's one thing Manager gets right). No model files needed for anything in this pack.

Gotchas

The only failure mode is the obvious one: if inStr isn't a parseable integer, Python raises a ValueError and the workflow errors out with a traceback. "42" works; "4.2" does not (that's String to Float's job); "" and "abc" both explode. So validate your request payload, or keep this node fed only by strings you control.

One more thing worth knowing: the pack's author wrote it specifically to sit after RequestInputs, and it's forgiving about that pairing. If your JSON already sends real integers, int() handles both int and str fine - so you can leave this node in place and it degrades gracefully. It's a tiny utility, but it's the kind of glue that keeps an API workflow from being a wall of type errors.