How to use a node's mode: On Event, On Trigger...

[ntdviet]

Hi,
can someone show me where to find the doc for this issue?
Or a screenshot of an example.
I'd appreciate your help!

[linnkoln]

same question

[M1kep]

• Always: Executes whenever itself or its inputs have been modified since the last run.
• Never: This node is essentially treated as non-existent. However, this can lead to complications. For instance, if any nodes rely on the output from a node set to "never", they will encounter an error.
• On Event/On Trigger: This option is currently unused.

Additionally, there's an option not discussed here:

Bypass (Accessible via Right click -> Bypass): Functions similarly to "never", but with a distinction. Instead of the node being ignored completely, its inputs are simply passed through. For instance, in a setup with multiple Lora Loaders, you can "bypass" one and it will effectively be skipped, allowing the data to flow through unaltered.

[Woisek]

For instance, in a setup with multiple Lora Loaders, you can "bypass" one and it will effectively be skipped, allowing the data to flow through unaltered.

Either it's not working (that way) or can only used for certain nodes.
I once wanted to bypass the FreeU node and got errors and the flow didn't work.

[VasiliyRyzhov]

Hi, everyone
Does somebody know, how to stop following node execution by output BOOL value of current node?

[enn-nafnlaus]

Hi, everyone Does somebody know, how to stop following node execution by output BOOL value of current node?

If by this you mean if you have a conditional node (such as from LogicUtil) and one input has been chosen, to not execute the inputs leading to the other input... then I would love that too. Can't figure out how to prevent unusued routes from executing . :(

[ltdrdata]

You can utilize Control Bridge and other logics nodes in Impact Pack.
https://github.com/ltdrdata/ComfyUI-Impact-Pack?tab=readme-ov-file#logics-experimental

[enn-nafnlaus]

You can utilize Control Bridge and other logics nodes in Impact Pack. https://github.com/ltdrdata/ComfyUI-Impact-Pack?tab=readme-ov-file#logics-experimental

Hey, thanks for this! I'm not sure it'd work in all circumstances (can't bypass all situations), but I was able to employ it in my current one. Lots of neat looking stuff in that pack - I'm going to need to take some time to go over it all :) You might want to consider updating the description for it - the description makes it sound like it's mainly for face detailing, which led me to skip it, thinking it was mainly "tools for waifus" :) Instead it seems to deal with a lot of deficiencies in base ComfyUI!

[ltdrdata]

FaceDetailer can be used for detailing faces, but it's actually usable for general inpainting purposes as well. It was initially created because many people said they couldn't switch to ComfyUI since it lacked a DDetailer. Since then, it has evolved with many ideas, but it has become so extensive that recently, I've been consolidating new fun nodes into the ComfyUI-Inspire-Pack.

[enn-nafnlaus]

FaceDetailer can be used for detailing faces, but it's actually usable for general inpainting purposes as well. It was initially created because many people said they couldn't switch to ComfyUI since it lacked a DDetailer. Since then, it has evolved with many ideas, but it has become so extensive that recently, I've been consolidating new fun nodes into the ComfyUI-Inspire-Pack.

Well, regardless, thanks for your work! I should have figured it'd be a neat pack given that you also wrote the node manager, and I (like bloody everyone else) use that all the time ;)

[KLL535]

And who knows how to make the loaders (the first nodes in the chain) not all work "simultaneously" at the beginning, but, for example, the first group of loaders (for example Load Checkpoint1) loaded immediately, and the second group of loaders (for example Load Checkpoint2) WAITED for some event of the first group's completion and only then started working. Now they all load in bulk and this takes up all the VRAM and RAM memory and it is impossible to work. And if you make them execute "manually" one by one, then everything works much faster.

[brdann]

And who knows how to make the loaders (the first nodes in the chain) not all work "simultaneously" at the beginning, but, for example, the first group of loaders (for example Load Checkpoint1) loaded immediately, and the second group of loaders (for example Load Checkpoint2) WAITED for some event of the first group's completion and only then started working. Now they all load in bulk and this takes up all the VRAM and RAM memory and it is impossible to work. And if you make them execute "manually" one by one, then everything works much faster.

Trying to figure out the same thing -- need to load up the big model first that must go to VRAM and only then all the other smaller models that don't need VRAM

[FunnyFinger]

And who knows how to make the loaders (the first nodes in the chain) not all work "simultaneously" at the beginning, but, for example, the first group of loaders (for example Load Checkpoint1) loaded immediately, and the second group of loaders (for example Load Checkpoint2) WAITED for some event of the first group's completion and only then started working. Now they all load in bulk and this takes up all the VRAM and RAM memory and it is impossible to work. And if you make them execute "manually" one by one, then everything works much faster.

Trying to figure out the same thing -- need to load up the big model first that must go to VRAM and only then all the other smaller models that don't need VRAM

I want to be able to load a model (flux) for outpointing stuff in the workflow, then unload it from the memory, then load another model to generate an image. currently I have no option to do this. the two models load together even if one is not required at a certain point causing memory issues and failure to continue the workflow. Does anyone have a solution ?