Rotor Machine Positions

On a real Enigma, the operator read the day's starting letters out of a codebook and set three windows. This node is the codebook: you type the letters, it hands back a POSITIONS object for the encrypt node's positions input. One widget, one output, and it will ruin your afternoon if you don't understand what it's counting.

What the string means

positions is a plain string, default AAA, and its tooltip is the whole specification: "From left to right, where the rotors will start at, whitespace permitting."

Three things are packed into that sentence.

It's left to right, so character 0 is slot 0 - the leftmost rotor - not the one the signal hits first. If you've been reading Enigma writeups where the Grundstellung is quoted right-to-left (which many are), reverse it before typing.

Whitespace permitting means spaces are stripped rather than rejected. A A A and AAA are the same input; the node calls str_cleanup and throws away every whitespace character. So you can format a long setting legibly - A B C D - without breaking it.

Each character is a letter of that rotor's own alphabet, at that rotor's slot. The node itself only does the cheap check (must not be empty); the real validation happens when the encrypt node converts the string into indices, and it's specific about failure: positions has 3 entries, machine has 4 rotors, or rotor 1: 'Q' is not in its alphabet if you're using a reduced alphabet and typed a letter that isn't in it.

The off-by-one everyone hits

Here's the case that generates the "why doesn't my key fit" question. If you built the machine with a reflector_rotor rather than a static reflector, that reflector occupies slot 0 and the path rotors shift to slots 1, 2, 3. Positions are indexed against the full slot list, so a three-wheel machine with a reflector rotor wants four characters, not three.

That's not a quirk to work around, it's the machine being honest - the reflector has a rotation and therefore a starting position. But it does mean that "how many characters?" depends on how you assembled the machine, and you should check with Rotor Machine State Descriptor instead of counting wheels in your head.

The other counting trap is auxilliary_rotors on the machine node: those are real slots too, so they need characters as well even though the signal never passes through them. The descriptor lists every slot with its role, which is why running it once beats guessing.

Output, and rewiring it

rotor_pos is a POSITIONS object, and there is exactly one obvious destination: positions on the encrypt/decrypt node. Same type, direct wire, no conversion.

It's also worth knowing that the encrypt node emits a POSITIONS on its rotor_pos output, representing where the wheels ended up after the message finished. That's how you chain messages: run one stretch of text, take the ending positions, feed them into the next node as its starting setting. Which is both how real traffic worked - operators logged end positions - and how you'd build a puzzle where the key to stage two is the state at the end of stage one.

That chaining is fragile in exactly the way you'd expect. Change one character of the plaintext and every rotor position downstream shifts, so a message with a typo produces a completely different end state. If a puzzle stops reproducing, suspect a stray character in the text before you doubt the machine.

Installing it

Manager → 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

This is the lightest node in the pack - a string and a dataclass. The requirements file is anything but light, pinning torch, torchaudio, cryptography, stegano and invisible-watermark for features you may never open. Manager installs the same set, so if you're worried about your environment, the honest advice is: install once, deliberately, and know what changed.

A working recipe

Positions AAA with an Enigma-preset stepper and the default rotor I wiring and a real reflector gives you the classic setup: type AAAAA into the encrypt node and the wheels are visibly stepping, so five identical letters produce five different ciphertext letters. Set the starting letters to QWE and the whole ciphertext changes while the machine stays structurally identical.

If it doesn't - if AAAAA produces five identical characters - your stepper is wrong or missing, not your positions. Positions only set where the wheels start; the stepper is what makes them move, and no amount of key-setting will substitute for it.