Add 'constant' data value input nodes

[teward]

There are numerous times in workflows where it is useful or advantageous to have individual data input nodes for primitive datatypes (INT, STRING (both multiline and not), FLOAT).

However, these nodes are NOT provided as part of ComfyUI. There are numerous external node packs which include primitive datatype nodes.

This pull request is designed to make these part of ComfyUI in its 'extras' group of nodes.

---

Note that my coding style for nodes is to design a "base" node so that the bare minimum of changes are necessary for the actual nodes themselves to function. In this case, the _CONSTANT_BASE node acts as a structure defining the various data types for components of the node that are accepted later. And make sure that things're implemented before running. As such, however, because we only have to override a few small bits (RETURN_TYPES, RETURN_NAMES, and INPUT_TYPES definitions), the rest of the node base makes sure everything else "just works" without having to duplicate code. That's the only reason it was used here, because of how I code nodes.

Revisions / changes are welcome if necessary, but I think adding these primitive "constant" nodes would be a positive improvement and inclusion (it's also not a major set of changes).

[mcmonkey4eva]

Are you aware of the Primitive node?

[teward]

Are you aware of the Primitive node?

Yes, however usage for it is Unclear and is not as useful for new users without such documentation (hint: there is none). Unless there's more clear documentation on this node, it's not clear to other users of how to provide such static inputs/values to other components of nodes. Which is why I sort of "take" the primitive node and expand it to the core datatypes for ease of use for other users.

[Bocian-1]

Are you aware of the Primitive node?

Primitive nodes force additional widgets (control_after_generate and sometimes control_filter_list) which you can't remove or hide in group nodes. This makes them very cumbersome when you don't want those widgets. It's especially awful for group nodes, where you may have a bunch of them. If I converted some of my group nodes to use primitives instead of nodes like impact float, they'd be 2x+ as big and most widgets would at best be useless or at worst could completely break internal logic if you accidentally set some control_after_generate to anything other than fixed. And again, you can't hide those currently.

Personally, I'd prefer to just be able to hide these widgets in group nodes or have a second version of primitive that doesn't add them in the first place (would also make setting up group nodes less tedious as you wouldn't have to go through hiding everything each time), but as a last resort, this PR would also make me and others less dependent on custom nodes for this.

[asagi4]

Primitive nodes are annoying: They don't exist in API-serialized graphs and they can't be rerouted. They're kind of special snowflakes that have weird behaviour that differs from other nodes. Having constants serialized in the API format would make it easy to create "input nodes" in workflows that are decoupled from other parameters any specific node might need.

In addition to the nodes here, constant string nodes with dynamicPrompts set to false would also be useful.

[teward]

Primitive nodes are annoying: They don't exist in API-serialized graphs and they can't be rerouted. They're kind of special snowflakes that have weird behaviour that differs from other nodes. Having constants serialized in the API format would make it easy to create "input nodes" in workflows that are decoupled from other parameters any specific node might need.

In addition to the nodes here, constant string nodes with dynamicPrompts set to false would also be useful.

I think the last commit I made addresses this request, adding two additional String nodes that are non-dynamicInput(s).

[teward]

@comfyanonymous and others this PR has sat for a few months, any updates on acceptance?

[mijuku233]

It would be better to add Constant Primitive, when Constant Primitive is linked to an input, Constant Primitive is converted to the corresponding widget and maintained.

[teward]

It would be better to add Constant Primitive, when Constant Primitive is linked to an input, Constant Primitive is converted to the corresponding widget and maintained.

Primitive is a weird node that doesnt conform. Even if this were doable the core 'constant' nodes dont exist and need included anyways. So until theres a node for every base type its not really feasible to do that.

This PR is a step in the direction of inclusion but inclusion is VERY slow here.

[mijuku233]

I mean the Constant Primitive that complies with the specification. Add the corresponding widget according to the "input type" when first linked, and keep it as a constant node. It is more difficult to implement, but better than Primitive or a separate Constant Node.