VNCCS Pipe

If you've used rgthree's or Impact Pack's "pipe" or "bus" nodes, you already know the pattern: instead of dragging eight separate noodles - model, clip, vae, positive, negative, seed, steps, cfg - between every pair of nodes that need them, you bundle them all into one custom type and drag a single wire. VNCCS Pipe is that pattern, purpose-built for this pack's own VNCCS_PIPE type, and it's the backbone wiring behind most of the pipeline: VNCCS Emotions Generator, for instance, takes a pipe input built by exactly this node.

What's actually in the bundle

Every field is optional, which is the point - build the pipe up incrementally across your workflow and pull pieces out wherever you need them:

• model, clip, vae - the core checkpoint components
• pos / neg - positive and negative conditioning
• seed_int, sample_steps, cfg, denoise - the standard KSampler numbers
• pipe (type *, wildcard) - lets you chain an existing pipe in and extend it, rather than building one from scratch every time
• sampler_name / scheduler - enum pickers whose default value is literally (← pipe), meaning "don't override, pull whatever's already in the incoming pipe." That's a genuinely useful pattern: leave them untouched to inherit settings from upstream, or pick an explicit value to override just that one field for this branch of the workflow.
• lora_name, lora_strength, lora_options_json - this node can also apply a LoRA to the model/clip pair as part of building the pipe, so you don't need a separate loader node for the common case of one LoRA on the main checkpoint.

Outputs mirror every one of those fields individually - model, clip, vae, pos, neg, seed_int, steps, cfg, denoise - plus the bundled pipe itself, and sampler_name / scheduler typed specifically as SAMPLER_NAME / SCHEDULER_NAME rather than plain strings. That typing is deliberate, and it's also where the one real landmine in this node lives.

The RES4LYF trap

This is a documented, real compatibility problem, not a hypothetical. If you have the popular RES4LYF sampler pack installed - a third-party set of high-order solvers and schedules that's become genuinely mainstream for flow-matching models - it overwrites ComfyUI's core list of available schedulers rather than adding its own alongside them. VNCCS Pipe's sampler_name and scheduler outputs are validated against a specific expected list, and when RES4LYF has changed what that list contains, you get a wall of "Return type mismatch between linked nodes" errors on every downstream node - KSampler, FaceDetailer, UltimateSDUpscale, all of it - even though nothing about your actual workflow is wrong. This was diagnosed on the pack's own release thread by another community workflow author, confirmed by the pack's creator, and the fix is either disabling RES4LYF while you use VNCCS, or inserting Impact Pack's ImpactSchedulerAdapter between the scheduler output and whatever's receiving it, which prunes the list back down to what's expected.

How to install it

Ships 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 pick up missing dependencies once.

Common issues

"Return type mismatch between linked nodes" on sampler_name or scheduler, on a workflow that used to work. See above - check for RES4LYF first, before assuming your workflow file itself got corrupted. It's specifically the scheduler list that gets clobbered, so a sampler_name-only error usually points elsewhere.

A LoRA strength field errors with "could not convert string to float." Reported alongside the RES4LYF issue on the same thread - an empty strength_model/strength_clip value gets passed through as an empty string instead of a number. Make sure those fields actually have a numeric value set, even if it's just the default 1.