ImpactValueSender
Send any value to a receiver elsewhere in the graph, matched by link_id
- value
- signal_opt
- signal
Impact Pack has a small family of sender/receiver pairs - ImageSender/ImageReceiver for pictures, LatentSender/LatentReceiver for latents - that move a value between two points in a workflow without a direct wire, matched instead by a shared link_id rather than a graph connection. ImpactValueSender is the same pattern applied to plain values: strings, ints, floats, booleans, whatever. Its counterpart is ImpactValueReceiver, set to the same link_id, sitting wherever the value needs to arrive.
Why you'd bypass a normal wire
This lives in the README's "Logics (experimental)" section alongside the pack's loop and branch primitives, and that's the context it's built for: workflows that re-queue themselves, where a value computed in one pass needs to reach a different part of the graph that runs in a separate execution rather than downstream in the same one. A plain wire can't cross that boundary - a sender/receiver pair, matched by ID, can.
The inputs and output
value- wildcard-typed (*), so it accepts whatever you're sending.link_id(INT, default 0) - the pairing key. WhateverImpactValueReceivershares this samelink_idis the one that gets the value.signal_opt(optional, wildcard*) - an execution-order input. The pack has a broader pattern for forcing one node to run before another (itsExecution Order Controllernode works the same way: wire the thing that should run first into a signal, and pass the thing that should run later through it).signal_optmirrors that - it's for chaining this sender's execution to happen only after something else has completed, if the order matters for your workflow.
Output is a single signal (*) - this node is marked as an output node (it does its job as a side effect, sending the value to any matching receiver), but it also produces a signal you can chain forward into whatever needs to know the send has happened.
Installing it
No separate install - comes with the pack. Via ComfyUI Manager: search ComfyUI Impact Pack, Install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack
cd ComfyUI-Impact-Pack
pip install -r requirements.txt
(portable: python_embeded\python.exe -m pip install -r requirements.txt), restart. No models needed - this is pure value-passing logic.
Common issues
Receiver isn't getting the value. Check link_id on both ends first - a mismatch, even a typo, means the receiver never sees this sender's data and silently falls back to whatever default it's configured with instead of erroring visibly.
Receiver reports the wrong type or a fallback value. ImpactValueReceiver on the other end has its own typ setting (STRING/INT/FLOAT/BOOLEAN) that determines how the wildcard value gets interpreted - make sure that's set to match what you're actually sending here.
Not sure you even need this. If the value only has to travel forward through a normal, single-pass part of your graph, a direct wire is simpler and there's no reason to reach for a sender/receiver pair. This pattern earns its keep specifically when a value needs to cross between separately-triggered parts of a workflow - loop iterations, queue-triggered re-runs - where a plain wire genuinely can't reach.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| value | * | — | |
| link_id | INT | 00–9223372036854776000 | — |
| signal_optopt | * | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| signal | * | — |