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

[TheCalypso]

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.

[Vrganj]

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.

Unfortunately, it's a client limitation, I don't think much can be done from the server side of things.

[electronicboy]

This is generally just a data API, it's not really a goal of the API to transform data behind the scenes, any transformations would generally be better send to mojang as a feature request for the client to implement

[TheCalypso]

If Paper can't do anything about it, I close the ticket.