HT Conversion

ComfyUI is annoyingly strict about types. A KSampler wants an INT seed, a text node hands you a STRING, and "42" from a prompt is neither. HT Conversion, from HommageTools, is the two-cent bridge: one string in, string/int/float out, so the same value can feed whichever sockets you have.

What it is

One input, input_value (a multi-line string field). Three outputs:

• string_out - the stripped original.
• int_out - the value parsed as an integer.
• float_out - the value parsed as a float.

Parsing is forgiving: "42" gives you 42 and 42.0. "3.7" gives you 3 (int truncates) and 3.7. And if the string isn't a number at all - "hello" - you get 0 and 0.0 rather than an error. That last behavior is worth knowing: a non-numeric string silently becomes zero, which is almost never what you wanted. If you're feeding this free-form text, sanity-check the input upstream first.

Why it exists

Mostly, it exists to rescue numbers that arrive as text. The classic flow:

1. A prompt parser or parameter extractor pulls steps=28 out of a text block as a STRING.
2. HT Conversion turns that into an INT.
3. The INT goes into a KSampler or a dynamic scheduler node.

It also plays nice with the pack's HT Dynamic Prompt output, where token counts and values come back as strings that downstream numeric nodes refuse to eat.

There's a real question of whether you need it at all: a lot of modern ComfyUI accepts strings in numeric sockets and coerces them. But "a lot" isn't "all", and when a third-party node rejects your string, this is a five-second fix with zero configuration.

Installing it

Part of HommageTools - no standalone install. ComfyUI Manager → search HommageTools, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ArtHommage/HommageTools.git
cd HommageTools && pip install -r requirements.txt

Restart ComfyUI, find it under the HommageTools menu.

The honest take

This is a genuinely thin utility - the source is barely 40 lines - and it shows in exactly one limitation: it does one scalar at a time, not lists. If you need to convert a whole batch of values, look at a list-aware converter instead. And remember the zero-on-failure behavior; that's the single trap in the whole node.

For a "string → number" problem, it's the boring, correct tool. Wire the three outputs anywhere and stop fighting the type system.