Eclipse KSampler (Kargim)

The KSampler is where a generation actually happens, and most of them sit there with ten loose wires feeding in. Eclipse KSampler (Kargim) is the version that plays the pipe game: you can feed it a whole context pipe and it samples, decodes, and hands back an updated pipe - so the next node in your chain starts from the state this one ended with, no re-wiring.

What it is

A full-featured sampler node (it's an output node - it runs unconditionally) with a pipe-first design. It accepts an optional pipe containing model, vae, conditioning, and sampling settings, plus direct inputs for every component. The twist is a priority system and an allow_overwrite flag that decide who wins when the pipe and your widgets disagree. It also handles the seed bookkeeping (-1 random, -2 increment, -3 decrement) and can VAE-encode an image for you if you hand it an image instead of a latent.

The "Kargim" in the name is the author's signature on a sampler preset lineage - the defaults here (res_multistep sampler, simple scheduler, 8 steps, CFG 1.0) are tuned for distilled/fast models where low-step, low-CFG sampling is the norm, so it's a natural fit for Flux and other few-step checkpoints.

How it works

The resolution logic is worth understanding, because it's the whole reason allow_overwrite exists:

• Model/vae/conditioning/latent/image sockets: a direct wire always wins over the pipe, regardless of the flag.
• Widgets (steps, cfg, seed, etc.): if the widget is physically wired from another node, the wire wins. Otherwise, with allow_overwrite off (default), your local widget value wins over the pipe; with it on, the pipe's values override your widgets.
• Unset values fall back to the pipe, then to defaults (8 steps, CFG 1.0).

Practical translation: leave allow_overwrite off and the widgets are authoritative; turn it on when you want the pipe (say, from a Context Image) to drive everything. The output pipe is rebuilt with the resolved model, vae, conditioning, latent, image, and settings - so downstream nodes inherit exactly what was used.

It also supports tiled VAE decoding (tiled_decode, tile_size) for big images, a preview_mode toggle to hide the live preview, and it writes the resolved seed back into the workflow so reproducible runs aren't guesswork.

Inputs that matter

• pipe - optional; the context to sample from (Context Image / Context Video output).
• model / vae / positive / negative / latent - or image if you want it to VAE-encode first. Either latent or image must be provided.
• steps / cfg / denoise / sampler_name / scheduler / seed - the sampling recipe.
• allow_overwrite - the pipe-vs-widget priority switch.

Outputs

pipe (updated context), plus model, vae, positive, negative, latent (denoised), and image (decoded). Wire the pipe onward or grab the image straight off.

Install

Part of ComfyUI_Eclipse (formerly RvTools, rewritten in v4.0.0). Manager → ComfyUI_Eclipse → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse

Under Eclipse → Sampler. No model downloads - bring your own checkpoint.

Troubleshooting

• "A model must be provided" error: the pipe was empty and nothing was wired to model. You need either a pipe with a model or a direct connection.
• Settings ignored / unexpectedly overwritten: this is allow_overwrite. If the pipe is driving values you thought you'd set in the widgets, flip the flag or check what the pipe contains. Remember: wired widget inputs always beat the pipe.
• Preview too noisy for large batches: set preview_mode to None; it hides the per-step previews and keeps the layout clean.
• Seed keeps changing: control_after_generate behavior - set widget control mode to "Before" once to see the seed that actually ran.