Gender Control Output

This is BooleanControlOutput's sibling, built for a three-state input instead of a plain boolean: gender_prior, which takes an empty string, M, or F. The README describes it exactly: "determines the output based on the input gender. If the gender input is 'M', it will output male-specific text, float, and integer values. If the gender input is 'F', it will output female-specific text, float, and integer values." It's a conditional-output node aimed specifically at workflows where prompt text, and sometimes numeric parameters, genuinely need to differ depending on the subject's gender - portrait pipelines, character-generation templates, anything where "attractive man" and "attractive woman" aren't interchangeable substitutions of a single word.

This node isn't alone in the pack on this theme - GeminiPromptEnhance has its own gender_prior/gender_alternative pair for the same purpose at the LLM-rewrite level, and the README separately describes a ModifyTextGender node that adjusts existing text based on gender rather than picking between two pre-written blocks. GenderControlOutput is the simplest of the three: you write both versions of the text yourself, up front, and this node just picks which one comes out.

Inputs: gender_prior is the required enum driving the whole node - blank, M, or F. male_text/female_text (multiline strings, both required) are the two text blocks you're choosing between. male_float/female_float (default 1, step 0.1) and male_int/female_int (default 1, step 1) are the numeric equivalents, for cases where something beyond text should differ too - strength values, seed offsets, whatever your pipeline needs to vary. gender_alternative is optional - a string field, presumably a fallback used when gender_prior is left blank, though the schema doesn't spell out its exact fallback behavior beyond that, so it's worth testing with a blank gender_prior once to confirm how your specific setup resolves it before relying on it in production.

Outputs: gender_text, float, int give you the selected values. is_male and is_female are booleans reflecting which branch got taken - chain these into other switch-pattern nodes in this pack (BooleanControlOutput, the various …Switch nodes) if you need the same gender decision to control more than just this one node's text and numbers.

Install: search "ComfyUI-utils-nodes" in ComfyUI Manager, or git clone https://github.com/zhangp365/ComfyUI-utils-nodes into custom_nodes, restart. No models or API keys - pure graph logic.

What to watch for:

• Both male_float/female_float default to the same value (1) and both int fields default to the same value (1) too - unlike BooleanControlOutput's asymmetric true/false defaults, this node ships with both branches identical until you actually edit them. Don't assume the defaults already encode a meaningful difference; you have to write both text blocks and, if relevant, both numeric values yourself.
• With gender_prior blank, behavior falls to whatever gender_alternative resolves to - verify this once against your actual use case rather than assuming a blank prior behaves like one specific gender by default.
• Because is_male/is_female exist to drive other nodes downstream, the same trap as BooleanControlOutput applies: if several nodes in your graph are gated on this node's outputs, changing gender_prior once should cascade everywhere correctly - but it's worth tracing every consumer the first time you build a graph like this, rather than assuming a single toggle change reached every node you meant it to.