Remove default float step

[bitegw]

Describe the project you are working on

Any project

Describe the problem or limitation you are having in your project

I want to change a float to a precise number that is smaller than the default float step. Even when I type the specific number manually, my input is ignored and the number is rounded.

The real issue with default_float_step that I want to bring to attention here is that it is an arbitrary number:

• When trying to change a large number the step is too low and it's better to just type the new value.
• When trying to change a really small number the user has to change the default float step to be able to do it or add a property hint, even typing the value directly does not work and it seems like a consequence of the implementation, rather than intended behavior.
• Even for simple changes like changing a 5 to a 7, it's again better to type the value directly to avoid overshooting because we generally don't want to end up with a number like 7.021.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Remove the default float step from property (and maybe CanvasItem and Transform3D?) - instead use the current precision of the number. For example, when dragging certain numbers:
0.05 -> 0.06, 0.06, 0.07...
22.5 -> 22.6, 22.7, 22.8...
3 -> 4, 5, 6
10 -> 11, 12, 13

This works for simple and small numbers, for larger ones it's still better than the current solution but it might be further improved with an exponentially larger increment (something like 10 -> 20, 30, 40; 100 -> 125, 150, ),I want to keep this proposal simple however, so this will not cover that.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Replace EDITOR_GET("interface/inspector/default_float_step"); in EditorProperty with a function that gets the precision of the current property value:

double get_precision(double value) {
    int step_power;
    double p = value;
    while (Math::floor(p) != p) {
        p *= 10;
        step_power += 1;
    }
    return 1 / Math::pow(10, step_power);
}

If this enhancement will not be used often, can it be worked around with a few lines of script?

Yes, either changing the default float step to a very low value (and making it worse when editing other values), or adding a property hint when we want to set a precise number (on every such property). So both solutions have downsides.

Is there a reason why this should be core and not an add-on in the asset library?

It improves default editor behavior that is very commonly used.

[girng]

that honestly sounds like a bug if your input is being ignored/rounded. could be related to godotengine/godot#97617

When trying to change a really small number the user has to change the default float step to be able to do it or add a property hint, even typing the value directly does not work and it seems like a consequence of the implementation, rather than intended behavior.

i did some testing on 4.3 stable with default float step to 0.000001

@export_range(0.1, 1.0) var k5 = 0.00
@export var k6 = 0.00

when i put 0.002 in k5, it gets set to 0.1
when i put 0.002 in k6, it gets set to 0.002

make sure if you're using @export_range, the min value in the range is at or below the number you're gonna set the variable to. for example @export_range(0.002, 1.0) works on k5, and 0.002 gets set correctly.

If this enhancement will not be used often, can it be worked around with a few lines of script?
Yes, either changing the default float step to a very low value (and making it worse when editing other values), or adding a property hint when we want to set a precise number (on every such property). So both solutions have downsides.

i feel like it's going to be really hard to please everyone with floating point values :(. the editor already gives the game developer so much power with setting values

also keep in mind, the slider's width (or dragging) scale's with the float step. having a step so small and having it work with a slider will be extremely cumbersome that can extend over the width.

in your example, let's say i do get to 13. what if i want to now slide and have it step in 0.05 increments to 13.05? there's no way to tell what the developer wants to do with their potential/future number. @export_range can be the solution for custom steps, or the dev can enter the number manually

[Calinou]

Thanks for the proposal! Consolidating in #3524.