Dropdown (obvpm)

Sooner or later every workflow grows a switch that says "do it this way or that way," and the first version is always two nodes you bypass by hand. The second version is a dropdown - and stock ComfyUI doesn't really give you a good one. (There's an experimental Custom Combo node in core now. More on that below.)

Dropdown gives you a list you type yourself, one choice per line, and puts the selection on a wire instead of burying it in a widget.

Inputs and outputs

Two widgets and three outputs.

options is a multiline field - one choice per line, blank lines ignored, surrounding spaces trimmed. selected is the pick, shown as a dropdown of those lines; leaving it empty means the first option.

The outputs are the useful bit:

• value - the selected line, verbatim, as a STRING.
• index - its position in the list, counting from 0.
• options - the whole list, unchanged.

That third output is what makes this more than a convenience. Wire options into a Lazy Case Switch's cases and value into that same switch's selected, and you have one source of truth: the dropdown choices, the switch's branch sockets, the branch labels, and the routing all come off the single list you typed. Add a line and a socket appears on the switch. Delete one and it goes away. The two nodes can't drift, because there's only one list.

You can also use it as plain data - an index into a set of filenames, a caption fragment, a style name that goes into a bundle.

How it behaves when you edit the list

Editing options refills the dropdown immediately. An empty selection resolves to the first option. And here's the design choice I like: if the line you had selected is later removed from options, the node raises rather than quietly picking something else. A saved workflow that silently changes meaning is worse than one that tells you to go re-pick. Same for an empty list - that's an error, not a None.

One implementation detail worth knowing because it explains the failure mode. The option list lives on the node instance, not in INPUT_TYPES - the frontend hands the combo widget a function for its list - while the input stays a plain string on the server side. The upside is that the node still functions as a text field if the pack's JavaScript doesn't load. The downside is that anything scripting your workflow without the frontend can't see the list; it's a string as far as the server is concerned.

Dropdown vs core's Custom Combo

Core ships an experimental Custom Combo node that also offers user-defined options, and if all you want is "a dropdown with my own entries," it does that. The difference is what the list is. Here it's a plain multiline string sitting on the node: visible on the canvas, editable in a text editor, diffable in git, and - the important one - wire-able into something else. Custom Combo's options aren't a value you can route anywhere. If you're going to build a switch on top of the list, that distinction is the whole ballgame.

The same "values are just strings on wires" philosophy is why this pack composes with itself so well; the plumbing notes on comfyui-ecosystem.md cover the general tension here, by the way - type-erasing convenience nodes make graphs easier to build and harder to debug. A dropdown is about as harmless as that trade ever gets, since you can see the entire content of the wire in the widget.

Install

Manager, search comfyui-obvpm, or:

cd ComfyUI/custom_nodes
git clone https://github.com/chanon/comfyui-obvpm

Restart ComfyUI. No Python dependencies to install (the pack declares none - torch, numpy, PIL and friends all come with ComfyUI already), no models, no setup. Every node in the pack is suffixed (obvpm) in the node menu, so searching obvpm lists the lot.