EASYUSE_ANIMA_PROMPT_DATA

The pack moved to a single EASYUSE_ANIMA_PROMPT_DATA socket with Prompt Studio Advanced v2, and it's the right call - one dict instead of ten strings. But you can't just rip the old wiring out of every workflow, and sometimes you want to tweak one value without re-opening the editor. That's exactly what this node, confusingly named after the socket type, is for: it passes the dict through and unfolds it into the old compatibility outputs.

What it does

One required input, EASYUSE_ANIMA_PROMPT_DATA, straight from Prompt Studio Advanced v2 (or any node that emits the type). It reads the dict by key and re-emits everything the old v1 editor used to output:

• positive_prompt, negative_prompt - the assembled prompts
• anima_mod_guidance_quality_tags, anima_mod_guidance_negative_prompt - quality fields routed to Mod Guidance
• use_anima_mod_guidance, use_negative_anima_mod_guidance - the booleans for workflow control
• metadata_prompt, metadata_negative_prompt - metadata outputs with metadata filters applied
• width, height - the latent resolution

And, crucially, EASYUSE_ANIMA_PROMPT_DATA also comes back out the other side unchanged, so you can chain it mid-stream without breaking a downstream prompt-data consumer. It's a pass-through with a compatibility harness bolted on.

The overrides are the fun part

On top of unfolding, every optional input on this node is an override for the corresponding dict key. Wire nothing and it's a pure pass-through. Wire a width INT into it and the width it emits - and the width that lands in the passed-through dict - is your override instead of the editor's value.

This is genuinely handy in a few situations:

• A workflow that loads another person's JSON and you want to force a resolution without hunting through popups.
• A/B testing: swap in a different negative prompt from a text node and keep everything else from the editor.
• Bridging: you've upgraded to v2 but a downstream node still wants positive_prompt and negative_prompt as separate strings. This node is the adapter.

The override inputs match the dict keys exactly - positive/negative prompt, both mod-guidance quality strings, both mod-guidance booleans, both metadata prompts, and width/height. Nothing invented, nothing extra.

Where it sits in a workflow

Two common layouts:

1. v2 editor → this node → Easy Use Anima Input. The dict passes through untouched (the generator only reads the dict), and you get the string outputs free for logging or metadata nodes.
2. v2 editor → this node → KSampler-era nodes. You keep using v2's editor but feed the old string-based Prompt Builder-style downstream nodes, because some of them never learned to read the dict.

Install and gotchas

Pack install, same as the rest:

cd ComfyUI/custom_nodes
git clone https://github.com/n0va39/ComfyUI-EasyUseAnima
cd ComfyUI-EasyUseAnima && pip install -r requirements.txt

Restart ComfyUI; Manager knows it as part of "ComfyUI EasyUse Anima".

Gotchas are mild. If you connect an override and nothing changes, check the type - width/height are INT sockets, so a FLOAT from a calculator node won't snap in. And if you use this node purely for the pass-through, remember the dict output and the string outputs come from the same read; an override changes both. One last thing: don't reach for this node to store state - it holds no state of its own, it's a pure function of its inputs, which is exactly what you want from an adapter.