FL Float to Int

FL_FloatToInt is a tiny type-bridge node: it takes a FLOAT and gives you back an INT, with your choice of how the rounding actually happens. You reach for this whenever something upstream gives you a float - a math node, a slider, an average, whatever - and something downstream demands a strict integer: a frame count, a batch size, a resolution value, a seed.

The four rounding modes matter more than they look. rounding_mode is an enum with round, floor, ceil, and truncate, defaulting to round. floor always rounds down, ceil always rounds up, truncate chops the decimal off toward zero - all three of those behave exactly the way you'd expect from any language's basic math functions. round is the one worth pausing on: per the pack's own documentation, it's banker's rounding, not the "round half up" behavior most people assume by default. Banker's rounding rounds .5 values to the nearest even integer - so 2.5 becomes 2, not 3, while 3.5 becomes 4. It's the same convention Python's built-in round() uses, and it exists to avoid a statistical bias that accumulates if you always round .5 the same direction across a lot of values. But if you're not expecting it, and your pipeline happens to produce a lot of values landing exactly on a .5 boundary, you'll see results that look "off by one" in a way that seems inconsistent until you realize it's alternating by design.

float_value is the input (default 0), and the single output is int_value.

Installing it is the standard Fill-Nodes routine - search "Fill-Nodes" in ComfyUI Manager, or clone it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

• then restart ComfyUI. This node has zero dependencies of its own; it's a few lines of arithmetic.

Troubleshooting. There's really one gotcha here, and it's the rounding mode. If a value that should be an exact half-integer is coming out rounded in a direction you didn't expect, check whether you're on round and whether the value in question happens to land on a .5 boundary - that's banker's rounding doing exactly what it's supposed to, not a bug. If you need fully predictable, direction-guaranteed behavior regardless of what the fractional part happens to be, switch to floor, ceil, or truncate instead of fighting round's default - those three have no ambiguity in how they treat the edge case.