RiceRound Str To Float

This is the conversion sibling of RiceRoundFloatNode, and it exists for a specific situation: the number you need isn't sitting in a native FLOAT widget, it's already a STRING somewhere in your graph - piped out of RiceRoundInputTextNode, or the wildcard value output of RiceRoundSimpleChoiceNode, or anywhere else text ends up flowing. RiceRoundStrToFloatNode takes that string and hands you back a real FLOAT you can wire into a CFG scale, a denoise strength, a blend weight, or anything else expecting a decimal.

What's genuinely different from the native Float node

RiceRoundFloatNode gives you a proper FLOAT widget plus min/max bounds to constrain what an end user can submit. This node doesn't have that - no range fields in its schema at all. Whatever the string parses to is what you get. If bounding the value matters for what's downstream (and for most diffusion parameters, it does), you're either validating it yourself before this node, downstream after it, or you'd genuinely be better served reaching for RiceRoundFloatNode directly if the value doesn't actually need to start life as text.

The inputs and output that matter

• name (STRING, default "数值" - roughly "value" or "number" in Chinese) - the label for this field.
• str (STRING) - the text being converted.
• Output: value (FLOAT) - the parsed number, wired anywhere a core FLOAT widget's output would go.

Installing it

ComfyUI Manager: search "RiceRound," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/RiceRound/ComfyUI_RiceRound

then restart. No requirements.txt and no model weights are called out in the README for this pack - it's a packaging and upload layer over a workflow you've already built, not something with its own inference dependencies.

Common issues & troubleshooting

Values outside a sane range are getting through and breaking your workflow downstream. That's the tradeoff of this node compared to RiceRoundFloatNode - there's no min/max here to clamp what comes out, so an unreasonable input string produces an unreasonable float with nothing in the node itself to catch it. Add your own guard downstream, or use the native Float node if bounded input actually matters for this field.

A malformed or empty string isn't converting the way you expect. The README doesn't document the exact parsing behavior for this node, so don't assume it silently falls back to zero or errors cleanly - test with a genuinely broken input string once locally and see what actually happens before you publish something that depends on graceful failure.

You're not sure whether this belongs in the workflow you publish. It does - it's Input-category, which per the README is exactly the family of nodes meant to end up in the graph you feed into RiceRound Publish. The nodes to leave out are the separate Output-category debugging nodes.