Object Modifier Move To Index

This is the precision version of Object_ModifierMoveDown. Object_ModifierMoveToIndex wraps bpy.ops.object.modifier_move_to_index(), which moves a named modifier directly to an arbitrary index in the stack - no shoving it one slot at a time. You name the modifier, you give it a target position, it jumps.

Stack order matters because each modifier feeds the next. In the Avatar Graph rigging flow you'll often want a specific layout - mirror first, then subsurf, then solidify, with the corrective-smooth riding on top - and Object_ModifierAdd dumps everything at the bottom. When the stack is more than a couple of entries deep, clicking up/down mentally breaks down, and an explicit index is the sane way to say "this modifier goes third." It also plays well as a parameterized step: drive the index with a widget and the same graph can produce different pipeline orders.

The mechanism. The node sets your BPY_OBJ as active and calls the operator with the modifier's name and target index. Blender's modifier stacks are zero-indexed from the top; index 0 is the first-applied modifier. The input clamps at the ends, so an out-of-range index just lands the modifier at the top or bottom rather than erroring.

Inputs.

• BPY_OBJ - the object whose stack you're reordering.
• modifier - exact name of the modifier to move (string matching, as with all modifier nodes here).
• index - the target position, an integer starting at 0 for the top of the stack.

Output. BPY_OBJ, passed through.

Installing it. Part of Avatar Graph. ComfyUI Manager → "Avatar Graph", or:

cd ComfyUI/custom_nodes
git clone https://github.com/avatechai/avatar-graph-comfyui
cd avatar-graph-comfyui
python -m pip install -r requirements.txt

Restart with --enable-cors-header; pack requires Python 3.10.x (bpy==3.6.0).

Troubleshooting. The gotcha is index confusion - "index 0" being the top of the stack catches everyone once, because visually the modifier panel reads top-down. And if you're moving a modifier by name into a position you think is right but the output surprises you, audit the other modifiers in the stack too; this node moves one entry, it doesn't reorder the rest. For a two-modifier stack, Object_ModifierMoveDown is honestly simpler - reach for the index version once the stack gets deep.