Custom ControlNet Weights Flux From List

Stock ControlNet setups give you one number for control weight and one start/end window - apply this much guidance, from this step to that one. That's fine for most workflows, but sometimes you want the guidance strength to change smoothly across the whole generation instead of stepping on and off at fixed points. This node takes a list of floats and turns it into exactly that: a per-step weight schedule for Flux, built specifically to feed Kosinkadink's Advanced-ControlNet pack.

Why you'd want this

The two ControlNet parameters that matter most - how strong the condition is, and when during denoising it applies - are usually enough. But Flux ControlNets in particular are sensitive to weight: the community-recommended values for modern Flux unions run lower than the old SD-era default of 1.0 (closer to 0.65–0.9 depending on the condition type), and getting a single flat value right across an entire generation is harder than tuning a curve. This node is for when you want fine control over that curve - easing the guidance in, holding it, then tapering it off - rather than a single number and a hard window.

Important dependency to know up front: this node's outputs are typed specifically for the Advanced-ControlNet node pack (a separate install from KJNodes, by Kosinkadink) - CONTROL_NET_WEIGHTS and TIMESTEP_KEYFRAME only mean anything wired into that pack's Apply ControlNet nodes. If you don't have Advanced-ControlNet installed, this node has nothing to plug into.

How it works

You supply a list of float values - typically built with a small list-construction node elsewhere in your graph, or hand-populated - and this node packages them into the weight and timestep-keyframe objects Advanced-ControlNet's apply nodes expect. Each value in your list becomes the weight at a corresponding point in the schedule, giving you step-by-step (or block-by-block, depending on how Advanced-ControlNet applies it) control instead of one flat number.

The inputs and outputs that matter

• list_of_floats (required) - your weight schedule, as a list of float values.
• uncond_multiplier (optional, default 1, range 0–1) - scales how much of this weight schedule applies to the unconditional (negative) pass specifically.
• cn_extras (optional) - extra Advanced-ControlNet configuration passed through, if you're using additional features from that pack.
• autosize (optional) - an Advanced-ControlNet layout helper input, cosmetic to the node graph rather than affecting generation.

Two outputs: CN_WEIGHTS (CONTROL_NET_WEIGHTS type) - wire this into the weights slot of an Advanced-ControlNet apply node - and TK_SHORTCUT (TIMESTEP_KEYFRAME type) - a shortcut that wires directly into a timestep-keyframe input some Advanced-ControlNet nodes expose, saving you from adding a separate Timestep Keyframe node.

How to install it

• ComfyUI Manager - search KJNodes for ComfyUI, install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt (portable: python_embeded\python.exe -m pip install -r ComfyUI\custom_nodes\ComfyUI-KJNodes\requirements.txt), then restart.

Then, separately, install ComfyUI-Advanced-ControlNet the same way (Manager search, or clone the Kosinkadink repo into custom_nodes) - this node is only useful once that pack is present, since its outputs don't wire into anything else.

Common issues & troubleshooting

Nothing to connect the outputs to. This is the single most likely snag, and it's an install problem, not a config one - if you don't see a compatible weights input anywhere in your graph, you're almost certainly missing Advanced-ControlNet itself.

Guidance still looks too strong or too weak overall. Remember this schedules the shape of the weight curve, but the underlying scale still matters - check your list's actual values are in the range appropriate for your Flux ControlNet variant (again, generally well under the old 1.0 default) rather than assuming the shape alone fixes an overall-too-strong setup.

Unconditional pass behaving unexpectedly. Check uncond_multiplier - leaving it at 1 applies your full schedule to the negative pass too, which isn't always what you want if you're trying to keep guidance strength asymmetric between conditional and unconditional generation.