DA_Base_KSampler

Let's be upfront about this one: it's a straight copy of ComfyUI's own stock KSampler. Same inputs, same output, same behavior. The node's own description says as much - "executes standard diffusion sampling using the vanilla KSampler implementation." It's credited in the README as a port of WAS_KSampler from WAS Node Suite, which is itself now archived and unmaintained. The reason to have a second copy of a node ComfyUI already ships isn't capability - it's independence: this pack's own Sampler and Scheduler Selector From String nodes need a sampling node in the same family to plug into, and vendoring one means this pack's XYZ-comparison pipelines don't depend on an external pack (especially not an archived one) just to run the actual sampling step.

What it does

The inputs are exactly what you'd expect from KSampler: model, seed, steps (default 28), cfg (default 7), sampler_name and scheduler (the standard enum dropdowns), positive and negative conditioning, a starting latent_image, and denoise (default 1 - full generation from noise; lower it for img2img-style partial denoising). The single output is a LATENT, which needs a VAE Decode after it before it becomes a viewable image, same as any sampling node.

Where this actually earns a spot in a graph over the stock node: right after this pack's SamplerSelectorFromStringNode and SchedulerSelectorFromStringNode, inside a comparison loop. All three are built to work together, so there's no reason to reach outside this pack for the sampling step when you're already using its selector nodes to drive sampler_name and scheduler from loop variables.

Installing it

ComfyUI Manager: search DemonAlone-nodes-ComfyUI, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/DemonAlone/SimpeStringGenerator_ComfyUI

No dependencies or model downloads - it needs the same model/VAE setup any KSampler-based workflow needs.

Where people get burned

Because it's functionally identical to the stock node, it inherits the exact same footguns. cfg accepts values up to 100, but nothing near that is a sane setting for any model family - 5 to 9 is the normal range for SD 1.5/SDXL-style checkpoints, and guidance-distilled models (Flux, several 2026-era releases) typically want CFG around 1. And the sampler_name/scheduler pairing matters more than either choice alone: Karras and exponential schedules are safe on SD 1.5/SDXL and actively wrong on flow-matching architectures, where Euler-family samplers on beta or simple schedules are the better starting point. None of that is specific to this node - it's just standard KSampler behavior wearing a different name, so treat any KSampler troubleshooting advice as applying here too.