Rotor Machine Preset Stepper

A rotor machine is only a rotor machine because the wheels move. Everything else - wiring, plugboard, reflector - could be done with a big substitution table. The movement is where the security comes from, and it's what this node controls: two inputs, and it hands a STEPPER to Rotor Machine State.

type: Enigma or Odometer

Two behaviours ship here, and the difference is exactly the difference between a cipher machine and a car's mileage counter.

Odometer is the car. The rightmost wheel turns every keystroke; the next one turns when the wheels to its right are all sitting on their turn-over notches; and so on leftward. Predictable, periodic, and not what any historical cipher machine did - but it's genuinely useful for building puzzle mechanisms that behave like a counter, and it pairs nicely with alphabets that aren't letters.

Enigma is the real thing, and it's worth knowing what the code actually implements because the double-step is the part everyone gets wrong from memory. The rightmost rotor always steps. A rotor steps when the rotor immediately to its right is standing on its notch. And a rotor also steps when it is itself standing on its notch - that extra clause is what produces the famous double-step, where the middle rotor advances twice in a row. It's the difference between "sort of like Enigma" and a machine that will reproduce historical traffic.

k is the trap

k means "the rightmost k rotors step". Default 3. Its valid range is validated against the machine, and the failure mode is blunt: k must be in [1, N] for this machine.

So a two-rotor toy machine with the default widget fails. Four rotors with k = 3 works fine, and simply leaves the leftmost rotor frozen for the whole message - which is a feature if you meant it and a silent weakness if you didn't. Nothing warns you that one wheel is decorative; the ciphertext just looks like it came from a 3-rotor machine, because it did.

There's a second, harder stop: preset steppers can't be combined with auxilliary_rotors. The preset counts every rotor it's given, aux included, so the machine refuses the combination and tells you to use a rule or circuit stepper instead. If you need aux rotors behaving oddly, Rotor Machine Rule-Based Stepper is your node.

One small cosmetic note so it doesn't confuse you: the output socket comes out labeled STEPPER in caps rather than stepper. Source has a typo in the return declaration. Wire it anyway, it's the right type.

Installing it

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

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

No models, no cryptography, nothing heavy in the code path. The pack's requirements file is still the full spread - torch, torchaudio, stegano, invisible-watermark - which is a comical overkill for a stepping rule and a real risk to a working ComfyUI environment. Manager installs the same set into the same shared interpreter; the ecosystem has no isolation, so this is a pack-level cost, not a node-level one.

Which one would I reach for

Start with Enigma, k equal to the number of rotors, because that's the machine most people actually want and it gives you historical behaviour for free. Drop k below the rotor count only when you're deliberately freezing wheels to simplify a puzzle for a human solver - a frozen rotor makes hand-checking a message feasible.

And run Rotor Machine State Descriptor after you wire it: the descriptor's slot table prints each rotor's step direction and its rule, so you can see at a glance whether the leftmost wheel is being stepped at all. That's a lot faster than discovering it via a ciphertext that never changes in the way you expected. If you find yourself wanting per-rotor control instead of "rightmost k", that's the moment to switch to the rule-based stepper - it's the same engine with the rules exposed.