Nodes/MKRShift_Nodes/Affinity Export Plan
ComfyUI Node

Affinity Export Plan

Decide where your Affinity result goes before the pixels exist

By criskb·Created 7 months ago·Updated 5 months ago· 0
Affinity Export Plan
    • affinity_export_plan_json
    • manifest_line
    • summary_json
    asset_path
    target_layer_nameMKRShift Result
    placement_modenew_layer
    transport_plan_json

    The MKRShift host bridges work on a plan-first pattern, and Affinity Export Plan is where you make the decisions before the pixels exist. It doesn't write anything - it builds a JSON plan describing where your generated asset should land in Affinity: which file path, which layer name, and whether it should drop in as a fresh layer or replace an existing one. That plan gets consumed by Affinity Export Output, which does the actual file write, and from there the Affinity addon places it in your document.

    It sounds like bureaucracy, but it's the thing that makes the roundtrip repeatable. If you've ever eyeballed a layer name in the wrong document and had to redo a placement by hand, you get the appeal of declaring it in the graph.

    How it works

    The three required inputs are the plan. asset_path is the full path to the image file you'll write (the output node saves there, so it needs to be a real, writable location). target_layer_name defaults to "MKRShift Result" - the name the layer gets when it lands in the Affinity document. placement_mode has two options: new_layer drops in a fresh layer, replace_layer overwrites an existing one with that name. The difference matters: replace is idempotent (re-running the workflow updates the same layer instead of stacking duplicates), which is exactly what you want when you're iterating on a design and don't want the layer panel to look like a junk drawer.

    The optional transport_plan_json is where this gets interesting for roundtrips. The pack has a whole network-transport lane (endpoint plans, webhooks, OSC, watch folders), and this input lets you attach a transport plan to the export - so the plan can say not just "write to this path" but "and deliver it over this channel." If you're doing a pure local file handoff you can leave it empty; attach_transport_plan handles the absence gracefully.

    Outputs

    • affinity_export_plan_json - the full plan, wired into MKRAffinityExportOutput
    • manifest_line - a compact comma-joined line (layer name, placement mode, asset path) for manifests
    • summary_json - target layer, whether a path is set, whether a transport plan is attached, warnings

    Installation

    cd ComfyUI/custom_nodes
    git clone https://github.com/criskb/MKRShift_Nodes
    

    Restart ComfyUI, or search "MKRShift Nodes" in ComfyUI Manager. No pip dependencies - it's JSON construction.

    Common issues

    The common failure is treating the plan as a shortcut for the output. This node emits text; without MKRAffinityExportOutput wired to it, nothing gets written to disk. Second, an empty asset_path doesn't error - it produces a plan with has_path: false and a warning, and the output node then falls back to its default filename in the working directory, which is almost never the place you wanted. Third, on replace_layer: it's a promise to the addon, not a guarantee - if the addon's document doesn't actually contain a layer by that name, replacement behavior depends on the addon's implementation, so verify the layer name matches exactly (the plan defaults are your friend here; custom names are where typos hide). Keep the plan explicit and wire the JSON through, and the Affinity half of the roundtrip stops being the part you babysit.

    CategoryMKRShift Nodes/Addons/Affinity

    Inputs (4)

    NameTypeDefaultDescription
    asset_pathSTRING
    target_layer_nameSTRINGMKRShift Result
    placement_modeCOMBOnew_layer2 options: new_layer, replace_layer
    transport_plan_jsonoptSTRING

    Outputs (3)

    NameTypeDescription
    affinity_export_plan_jsonSTRING
    manifest_lineSTRING
    summary_jsonSTRING