DialogInput.numberRange displays floating-point artifacts (e.g. 19.900002) despite clean float inputs

Expected behavior

When using DialogInput.numberRange with a float step (e.g., 0.1f) and a clean initial float value (e.g., 19.9f), the client-side UI should display the value cleanly as "19.9".

Observed/Actual behavior

The client UI displays floating-point artifacts, showing values like "19.900002" or "2.8000002" instead of the expected clean decimal. This happens even when the initial value and step are explicitly defined as clean floats.

Steps/models to reproduce

// Create a Dialog with a number range input using float values
DialogInput.numberRange("initialTime", Component.text("Initial Time"), 0.1f, 60f)
    .initial(19.9f) // Clean float literal
    .step(0.1f)     // Clean float step
    .build()

// Open this dialog to a player and observe the slider value.

Plugin and Datapack List

Paper version

Other

We have attempted several workarounds to fix this display issue, but none were successful due to API limitations:

1. Rounding the Initial Value:
   We tried Math.round(val * 10.0) / 10.0 before passing it to .initial(). The issue persists because the step(0.1f) addition causes immediate floating-point drift in the client view.

2. Using BigDecimal:
   We attempted to use BigDecimal for precision:
   .initial(BigDecimal.valueOf(val).setScale(1, RoundingMode.HALF_UP).floatValue())
   However, since the API only accepts float for initial() and step(), converting back to float reintroduces the precision errors.

3. Visual Workaround (Integer Multiplier):
   We tried scaling values by 10 (0-600 range) to use integers and adding "(x0.1)" to the label. This fixes the display but degrades UX as users must mentally calculate the decimal.

Suggestion:
It would be helpful if DialogInput supported double orWe have attempted several workarounds to fix this display issue, but none were successful due to API limitations:

1. Rounding the Initial Value:
   We tried Math.round(val * 10.0) / 10.0 before passing it to .initial(). The issue persists because the step(0.1f) addition causes immediate floating-point drift in the client view.

2. Using BigDecimal:
   We attempted to use BigDecimal for precision:
   .initial(BigDecimal.valueOf(val).setScale(1, RoundingMode.HALF_UP).floatValue())
   However, since the API only accepts float for initial() and step(), converting back to float reintroduces the precision errors.

3. Visual Workaround (Integer Multiplier):
   We tried scaling values by 10 (0-600 range) to use integers and adding "(x0.1)" to the label. This fixes the display but degrades UX as users must mentally calculate the decimal.

Suggestion:
It would be helpful if DialogInput supported double or BigDecimal to handle precision correctly, or if there was a way to specify a display format (e.g., %.1f) for the client UI to hide these artifacts.

Start at the DialogInput.numberRange API and trace how its float initial value and step are represented for the client UI. Reproduce the example with 19.9f and 0.1f, then identify where the displayed value gains its floating-point artifacts. Done means the slider displays clean decimal values without breaking the existing number-range behavior.