MiniMax H3 R42 · Editor Shot / Master Policy

The R42 "Universal Delivery" system is built to make several proven delivery pipelines share one graph, and it has a specific headache to solve: when you render a long film as a chain of H3 segments, the editor nodes downstream want to see the whole thing as one film, not twenty files that happen to be numbered. IAMCCS_MiniMaxH3UniversalEditorPolicyR42 is the adapter that handles that - it changes how the editor-facing copy of the plan behaves without ever touching the generation truth underneath.

Read the code and the principle is explicit: "Generation truth is never changed." This node doesn't alter what the samplers render or what the checkpoint saves. It takes the cine_linx plan object, and if the selected route is one of the master-delivery routes (the LTX master path), it produces a modified copy flagged for editor consumption. The task mode becomes longvid_r42_one_film_delivery, and it records the original task mode plus the delivery route so nothing downstream is confused about what changed. For any other route it passes the plan straight through unchanged - native, windowed, fast and per-shot LTX deliveries keep their normal editorial-roll behavior.

Why "one completed programme"? In master-delivery mode, the native checkpoint queues and merges every segment before LTX ever starts, precisely so the LTX master stage receives a complete film rather than a final isolated chunk. This node is the editorial half of that deal: it tells the editor nodes "this run publishes as one finished master," which is the same policy the author's LongVid path already used. It's consistency plumbing, and it's the difference between an editor UI showing you a film and showing you a pile of segments.

Inputs and outputs

One input - cine_linx, the framework plan object. Three outputs:

• editor_cine_linx - the adapted plan copy for editor-facing nodes.
• one_film_delivery (BOOLEAN) - true only when the route is a master route; downstream editor nodes read this to decide how to present the result.
• report - which route was seen and whether it publishes shot-by-shot or as one master.

If you're hand-wiring R42, you'd connect this node's output to the editor-facing parts of the graph and keep the raw cine_linx feeding the actual delivery branches. That split - raw plan for generation, adapted plan for editorial display - is the entire trick.

The honest take

This is not a node you'll ever reach for in isolation. It exists because R42 deliberately routes one film through a whole chain of delivery adapters, and without it the editor layer would mislabel a one-film master run as shot-by-shot (or vice versa). If you're following an R42 reference workflow you'll drop it in exactly where the template shows it and forget it's there - which is the correct relationship to have with policy nodes.

The thing to keep straight is which cine_linx is which. Connect the wrong one (raw into the editor, adapted into a delivery branch) and you get confusing behavior: an editor that thinks the run is one film while delivery is per-shot, or a master delivery whose editor thinks it's getting segments. The report output tells you which route it resolved, so glance at it once after wiring.

Install

Ships in IAMCCS-nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes

or via ComfyUI Manager (search "IAMCCS"), restart. Requirements are the H3/universal-delivery stack - current ComfyUI (≥ 3.x) with native MiniMax H3 support, Python ≥ 3.12, PyTorch ≥ 2.8, the H3 weights (~42 GB) and VAEs, and for the master routes an LTX pipeline it hands the finished film to. And the H3 licence caveat: no US, EU, UK or Korea.