VNCCS Sampler Scheduler Picker

Two dropdowns, two outputs, nothing more: pick a sampler_name (44 choices, default euler) and a scheduler (9 choices, default simple), and get them back out typed specifically as SAMPLER_NAME and SCHEDULER_NAME rather than plain strings. That typing is deliberate - it's how VNCCS validates that whatever you picked is actually one of the values its own KSampler-wrapping nodes expect, rather than letting a typo or an incompatible value slip through silently.

It's also, unfortunately, the exact node at the center of the single most-reported compatibility bug in VNCCS's release history.

The RES4LYF conflict, in detail

RES4LYF is a genuinely popular third-party ComfyUI pack of high-order samplers and schedules, built specifically for flow-matching models - and it's become mainstream enough that plenty of people have it installed for unrelated workflows without thinking about it. The problem is how it installs itself: rather than adding its schedulers alongside ComfyUI's core list, it overwrites that list outright. VNCCS's sampler and scheduler nodes - this one included - are built expecting the stock list, and when RES4LYF has silently changed what "the list" contains, every node downstream that receives a SAMPLER_NAME or SCHEDULER_NAME from this picker throws "Return type mismatch between linked nodes" errors, cascading through KSampler, FaceDetailer, UltimateSDUpscale and anything else in the chain.

This isn't speculation - it played out on VNCCS's own release thread. A user posted a wall of exactly these mismatch errors; another community workflow author identified RES4LYF as the cause with high confidence, based on having seen the same pattern repeatedly across other packs; the pack's own creator confirmed it, noting he could reproduce the symptom but couldn't tell in advance whose installs would be affected, since it depends entirely on what other sampler-modifying nodes someone happens to have installed.

The fix, straight from that thread: disable RES4LYF while working in VNCCS, or insert Impact Pack's ImpactSchedulerAdapter node between this picker's output and whatever's receiving it - it prunes the list back down to what the receiving node actually expects, at the cost of one extra node in the graph.

Why VNCCS needs its own picker at all

A basic sampler/scheduler dropdown exists in core ComfyUI too, so a fair question is why this pack has its own. The answer is almost certainly the strict typing: by exposing sampler_name/scheduler as VNCCS-specific types instead of plain strings, the pack's own nodes can validate connections at graph-build time rather than failing at runtime with a cryptic sampler-not-found error. It's a reasonable design choice - the RES4LYF conflict is really a case of two well-intentioned strict-typing systems stepping on each other, not a flaw specific to either pack.

How to install it

Bundled with the main pack:

• ComfyUI Manager - search VNCCS - Visual Novel Character Creation Suite, install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/AHEKOT/ComfyUI_VNCCS.git, then cd ComfyUI_VNCCS_Utils && pip install -r requirements.txt, restart, and let Comfy Manager grab any missing dependencies.

Common issues

"Return type mismatch" errors on sampler or scheduler fields. Check for RES4LYF first - see above. It's the single most common cause reported against this exact node.

Which sampler/scheduler pair to actually pick. That depends entirely on which checkpoint family your VNCCS pipeline is running - Illustrious and other SDXL-era checkpoints want a different pairing than a flow-matching model like Anima or the Qwen-Image-Edit backbone VNCCS 3.0 runs on by default. euler/simple, this node's defaults, are a safe flow-matching-friendly starting point; if you're still on an Illustrious-based VNCCS setup, a DDPM-style pairing like dpmpp_2m/karras is the more traditional choice for that architecture instead.