VRGDG_MuteUnmute4PromptCreatorWF_2

VRGDG_MuteUnmute4PromptCreatorWF_2 is the third and final of the trio of runtime mute/unmute/bypass nodes in this pack. Same class as _0 and _1, same inputs, same wildcard output - the only reason it exists is that ComfyUI needs distinct node names for multiple instances, and a three-stage batch pipeline needs three of them.

Where _0 starts the handoff (mute stage one, queue stage two) and _1 carries the middle, _2 is the terminal stage: it mutes what's done, activates the final stage's nodes, and - if you've left auto_queue_next off here, which is the sane setting for a last stage - the batch run ends and the workflow is back in your hands. There's no _3, and that's the design: the chain stops at three passes.

The mechanics are identical to its siblings, so I'll keep this short:

• signal - wildcard trigger; the node acts when it fires.
• group_count / group_action - slots used and the action (active / mute / bypass).
• group_1 … group_12 - named node groups to target, each with its own action override.
• node_ids_csv / group_targets_json - precise or JSON-driven targeting.
• auto_queue_next / queue_delay_seconds - normally left off on the final stage, but available if you genuinely want the chain to loop.
• Output signal_opt - passthrough wildcard.

When the third one matters

For the pack's intended pipeline - lyrics pass, prompt pass, generation pass - the final stage is where scene generation and enhancement actually run, and _2 is what makes sure the earlier stages' nodes are silent while it does. If you're adapting this pattern to your own graph, the lesson is more general: the trio is a template for "three-phase unattended batch," not something you have to use all of. A two-phase workflow can stop at _1, and a single phase only needs _0.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl

Restart ComfyUI; it sits under VRGDG/General beside its siblings. ComfyUI Manager: search vrgamedev.

Honest note

Be deliberate about which of the three you place where. Because they're identical classes, an easy mistake is wiring two of them to act on the same group in the same run, which muting logic will resolve in an order you may not have intended. Sketch the pass order on paper first: each of the three should touch a disjoint set of groups, and only the non-final ones should have auto_queue_next on.