Script input

Script input is the pack's answer to the question "what if my expression is too long for one line?" It's a multiline text box that produces a compiled syntax tree, which you then feed into any More Math node's expression field. Instead of cramming a whole program into the little string input on a math node, you write it here - with real line breaks, comments, helper variables, even functions - and wire the result into as many math nodes as you like.

How it works

The script is parsed by the same ANTLR-based grammar the pack uses everywhere, and the output is a SYNTAX_TREE (the pack's internal MrmthParseTree). The math nodes' expression inputs accept both plain strings and this tree type, so you can build a "math library" once in a Script input and share it across the graph.

The language inside supports a lot more than a one-liner can express. From the pack README, you get:

• custom variables: varname = expression;
• custom functions: funcname(x, y) -> expression;
• control flow: if/else, while, for, { blocks }, return, break, continue
• comments: # line and /* block */

The one rule that matters is the author's own framing: the last part of the script must be the expression that produces the result. Everything before it can set up state; the trailing expression is what gets evaluated and returned.

Inputs and output

• script - a multiline string. That's the only input.
• Output - a SYNTAX_TREE.

The output only connects to sockets that accept that type, which means the expression fields of the pack's own math nodes. If you're using ComfyUI's core nodes, there's nothing for this to plug into - it's specifically a More Math companion.

Installing it

Part of More Math (mcDandy/more_math). ComfyUI Manager - search "More Math" - or:

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

Restart. Dependencies are just antlr4-python3-runtime and torch - the grammar runtime is the whole point of that dependency. Needs a current ComfyUI.

Where people get burned

Parse errors. Because the script is compiled at execution, a typo in a function name or a missing semicolon surfaces as a red node, and the error can be terse. Keep the setup statements semicolon-terminated and make sure the final expression is actually the last thing in the box.

Second, scope discipline. Variables you define inside a { block } are isolated and don't leak out; modifications to variables that already existed do persist. That's Python-adjacent but not identical - if a value seems to reset mysteriously, you've hit block scoping.

Honestly, most users will never open this node. The one-line expression field on the math nodes covers the 90% case, and the pack's workflow examples only start reaching for Script input when an expression grows a helper function it wants to reuse. But if you're building a workflow with a genuinely complex computation, this is the tool that keeps it readable - and sharing one script across several math nodes means fixing the math in exactly one place.