Multishot Advance Project

The pain this node fixes is the one that makes long H3 work miserable: you render ten shots, decide shot 5 is wrong, fix the prompt, and the sampler wants to re-render everything because each later shot depends on the earlier shots' state. If you're lucky you burn the same GPU hours you already spent. If you're unlucky you also lose which shots were even done, because ComfyUI's session state died when you closed it.

Multishot Advance Project is the pack's flagship answer: a project/session layer that saves a named render state to disk, survives a full ComfyUI restart, and lets you edit one shot and resume from the first changed clip - reusing the safe earlier work instead of rebuilding it.

It is not a video archive. Final MP4s still land in ComfyUI's normal output folders. The project stores the editable render state: the effective shot script, per-shot prompt hashes, sampler/cache compatibility metadata, and the reusable cache-v2 shot artifacts with their verified manifest.

How it works

Folders live at ComfyUI/user/multishot_advance_projects/<readable_name>--<identity_hash>/. The short identity suffix keeps names that differ only by case or unsupported characters in separate folders - you type the clean project_name, folder naming is automatic.

The key behavior is dirty-shot invalidation. Change shot 2 of a three-shot project and the project marks shot 2 dirty. The sampler restores the safe prefix (shot 1), then re-renders shots 2 and 3. That's intentional, not lazy: later shots inherit memory/context state from earlier ones, so changing shot 2 must invalidate everything after it. You can't have it both ways with chained video.

The inputs that matter

• project_name - the named project. Set a stable one and leave it alone.
• mode - load_or_create is the normal write/update mode. read_only loads and reports without touching project.json. rebuild_project treats everything as dirty from shot 1 so the next run starts fresh.
• script - the shot script (----separated plain text or JSON prompt lists, same format the sampler accepts). Here's the reopen-next-day trick: if script is empty and a project with that name already exists, the node loads the saved script from project.json.
• shot_count - 0 uses the number of shots found in the script; higher repeats/truncates to exactly that many.
• apply_shot_override + override_shot_index + override_prompt - replace one effective shot before the project computes hashes and cache invalidation. In write mode the edited script becomes the saved project script.

Wire it in front of the sampler:

Multishot Advance Project.project        -> Multishot Advance Sampler.project
Multishot Advance Project.script_out     -> Multishot Advance Sampler.script
Multishot Advance Project.shot_count_out -> Multishot Advance Sampler.shot_count

Keep the sampler's shot_cache on use_cache - that's what makes reuse work. The optional prompt_builder_state input (from the Prompt Builder) stores the builder's editable fields in project.json, so reopening a project also restores your builder settings; pick the project in the builder's project_picker and its prompts come back.

Installing it

It's a core node in the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/KursatAs/ComfyUI-H3-Multishot-Advance

Restart ComfyUI. No separate model or dependency downloads beyond what the pack already needs.

Common issues

The realistic failure is disk space, not errors. The README's caution is blunt: project folders and shot cache files store raw reusable render state, not small text metadata, and they grow over time. Clean old projects manually under ComfyUI/user/multishot_advance_projects/ when you're done with them - there's no built-in garbage collector.

If a project "forgets" what it was doing, check that you're using the same project_name (the hash suffix means near-miss names get separate folders), that the sampler's shot_cache is on use_cache, and that you're not in read_only mode when you expected to write. And remember the resize-vs-reuse rule from the sampler's cache: the cache only reuses a shot when the settings that affect it still match - model, seed, resolution, frames, sampler, scheduler, references, continuity. Change any of those and the "safe prefix" shrinks, sometimes to nothing. That's correct behavior, but it surprises people who expected a cache to be immune to resolution changes.