Int Math (Badman)

The kind of node you don't think you need until you're three layers deep in a graph and realize you want a batch size divided by two, or a frame count plus a fixed offset, without dragging in a full expression-evaluator node pack for one operation. This is exactly that: two integer inputs, a pick-one math function, one integer out.

Why this exists

ComfyUI graphs end up doing a surprising amount of arithmetic that has nothing to do with diffusion - computing an output resolution from an input one, deriving a batch count from a total, offsetting a seed by a fixed amount across a loop, working out padding for a tiling operation. You can reach for a general-purpose Python-expression node for any of this, but that's a bigger, more powerful tool than most of these cases actually need, and it's arguably more room for something to go wrong for a one-line calculation. Int Math is the minimal version: pick your operation from a dropdown, wire two integers in, get one out. No syntax to get wrong, no expression string to typo.

Inputs and outputs

Three required fields:

• Int1, Int2 (integer, min 0, default 0) - the two operands. Note the minimum is 0 on both - this node's inputs are non-negative by design, which matters for sub in particular (see below).
• math_function - an enum with four options: add, multiply, sub, divide.

One output: the result, as INT.

Installing it

ComfyUI Manager: search ComfyUI-BadmanNodes, install, restart. Manual:

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

Nothing else needed - this is arithmetic on two numbers, there's no dependency to speak of.

Where people get tripped up

Two real gotchas worth knowing before you rely on this in a workflow you're not going to sit and watch run. First, divide: dividing two integers doesn't cleanly guarantee an integer result, and the schema gives no indication of whether this node rounds, floors, or truncates - worth a quick sanity test with known values before trusting it in anything downstream that expects an exact count (frame numbers, batch sizes) rather than an approximate one. Second, and more likely to actually bite you: dividing by zero. Int2 has a minimum of 0, and 0 is a perfectly valid value to land there - whether that produces an error, an infinity, or a silent zero isn't documented, so if a downstream node throws a confusing error or your graph just stalls, check whether a zero snuck into the divisor before chasing the problem anywhere else. And because both inputs are floored at 0 with no negative range, sub where Int2 is larger than Int1 is worth a quick test before you rely on it - the output itself has no documented floor, so don't assume it clamps at zero rather than going negative; verify which it actually does rather than guessing.