Rotor Machine State Descriptor

Rotor machines are the one place in ComfyUI where a mistake is invisible. A wrong VAE gives you a grey image; a wrong rotor order gives you ciphertext that looks exactly like correct ciphertext. This node is the answer to that: feed it a MACHINE and it prints out what you actually built - every slot, its size, its ring setting, its notches, its stepping rule, and the order of stages in the signal path.

It's not a cipher node at all. It's a debugger, and it's the first thing to drop on the canvas when a message won't decrypt.

One input, one output

The input is machine, a MACHINE from Rotor Machine State. That's the entire interface - no widgets, nothing to set. The output is description, and the node is declared as an output node, which is the important part: it runs unconditionally and its result surfaces in the node UI, so you read it rather than wire it. The declared type isn't STRING, so don't plan on piping it into a text-consuming node; treat it as a terminal that displays.

What the text tells you

The output has four parts, and each one answers a question you'd otherwise be guessing at.

The alphabet header - one line if input and output alphabets match, two lines if the machine changes alphabet along the way. That second form is your early warning that a mapper is in the chain, which is the usual suspect when a decryption produces plausible garbage.

The slot table - one row per rotor, with its role, alphabet size, ring position, notch letters, step direction and its stepping rule. The role column is the useful one: path rotors are in the signal path, aux rotors aren't, and reflector is the rotor-as-reflector case. This is where the "why does my position string need four characters" question gets answered, because you can count the slots instead of reasoning about how you assembled it.

The path listing - each stage in order, described by kind: rotor slot 2 forward, rotor slot 1 inverse, fixed 26->26, involution, or fixed 26->10, changes alphabet. If you've ever wondered whether the reflector actually reverses the signal, this is the line that proves it: you'll see the forward walk down the rotors, the reflector, then the same rotors coming back as inverse stages.

Notes - the genuinely opinionated part. It flags slots that "never step on their own" (a rule of never, which might be intentional and might be a typo), and it emits "path has no repeated stages: likely non-reflecting, so decrypt mode is required" when your machine has no reflector. That note is the single most valuable line in the pack, because a non-reflecting machine is not reciprocal - encrypting the ciphertext again won't decrypt it - and nothing else will tell you.

Installing it

Manager → search ComfyUI ARG Toolkit → install → restart → refresh the browser. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/AzelusLightvale/ComfyUI-ARG-Toolkit
pip install -r requirements.txt

Like the rest of the rotor category this is pure Python with no model downloads and no cryptography dependency. The requirements file still pins torch, torchaudio, stegano and friends, because it's one file for the whole pack - the usual ComfyUI tax where every pack's pins land in the same shared interpreter. Nothing about inspecting a machine justifies a torch reinstall.

Three ways to actually use it

As a build check. Wire it up the moment the machine node stops complaining. If the descriptor renders, your wiring, alphabets and stepper all validated - the machine node's own checks are strict, and a successful description is proof you got past them.

As a tie-breaker when a message won't decode. Compare what's printed against what you think you built. Ring settings of 0 vs 1, a notch letter that should be Q but is R, rotors chained in the wrong order - all of it shows up here and none of it shows up anywhere else.

As documentation. The description is plain text, so paste it next to your puzzle, or into a comment node in the workflow. Reproducing someone's rotor machine from a screenshot of widgets is genuinely painful; reproducing it from the descriptor's table is five minutes of typing. Given that these machines have no persistence and no names, that's the closest thing the pack has to saving your work.

One small thing you can ignore: the descriptor can print a Circuit line for circuit-style steppers, but the pack's node mappings don't currently expose one in the UI, so in practice that line never appears.