Exported int variables only display as sliders if their stepsize is set to something other that 1

[Arnklit]

Godot version: 3.2.3.stable

OS/device including version: Windows 10 Pro v.2004 / Inspiron 7373 Core i7-8550U / Intel(R) UHD Graphics 620

Issue description: Exported int variables don't show up as sliders. If you set the step size to something else that 1, they do. For some reason it works to set the step size to a float under 1 and then it will work as an int slider.

Steps to reproduce: Open attached project to see issue

Minimal reproduction project: export_int_issue.zip

[rsubtil]

Building upon this, why not simply add both options to those type of export'ed vars, like this?

It gives both a fine-grained control with the arrows, and more wide-grained control with the slider.

[aterlamia]

If i look at the documentation it it only says that the range is limited only for the last example it also says it shows a handy slider.

So in my expectations the first one should not show a slider.

The second one is debatable as a setting of 1 for slider is the same as not setting a step, but that might need to be documented.

And for the last case with the float i guess it is cast to a int, do we need to throw an error there or document that a float will be cast to a int in the step in case of a int slider?

Or do we just want uniform functionality for all these cases?

[Calinou]

Sliders are currently only displayed for floats, not integers. I think we should change this so integers also have sliders.

However, if we do that, we lose the "immediate" visual hint that some numbers are integers since they don't have an associated slider. I'm not sure if it's always worth losing that visual hint.

[aterlamia]

in the example project and screenshot above the exports on line 6 and 7 behave like integer sliders. Just tested that myself. In that case var 3 would be the error and var 4 just strange behavior if understand correctly?

But in that case i would say indeed keep sliders for floats only as only those need the ctrll to round / shift to be more precise functionality that the slider provides

[Arnklit]

@Calinou how about always showing a single decimal on floats even if they are whole numbers to indicate they are floats not ints? I know that would not be for this bug, but that might be a good proposal and then we could make ints have sliders consistently.

[aterlamia]

What does exactly need to be done here now?

If sliders should not show for integers none of the above should show a slider, am i correct?

Which does not work at this moment because in editor_spin_slider.cpp we first check

get_step() == 1

And if that is not true we check hide_slider, which is default set to false and not set to true for integers. So a slider is shown for all integer values with a step larger than 1

Does that need to be fixed or should i right away implement the changes as suggested?

An another question the example on line 7 should not be possible i think do we need a warning or an error there. Or is the functionality that it implicitly is cast to an integer how we want it?

[Bhu1-V]

Hello guys, where can i find the logic for the export keyword. I tried looking in godot/modules/gdscript/ path but found nothing.

Please Help me to find something about it.

[akien-mga]

@pWNn1sher you got the path wrong: https://github.com/godotengine/godot/search?q=export+path%3Amodules%2Fgdscript

[zak-grumbles]

Interested in picking this issue up. Was there ever a consensus on the desired behavior for integers?

[jcommander]

However, if we do that, we lose the "immediate" visual hint that some numbers are integers since they don't have an associated slider. I'm not sure if it's always worth losing that visual hint.

Agreed, but wouldn't it be possible to add an optional export hint for @export_range with a step = 1.0 so you could give both floats and ints the default float slider representation by choice. This would preserve visual identity by default and give a readable syntax if you decide a slider fits your variable better.

Example: @export_range(0, 10, 1, "decimal_style") var x: int or @export_range(0, 10, 1.0, "decimal_style") var y: float

[ulvido]

Godot version: 3.2.3.stable

OS/device including version: Windows 10 Pro v.2004 / Inspiron 7373 Core i7-8550U / Intel(R) UHD Graphics 620

Issue description: Exported int variables don't show up as sliders. If you set the step size to something else that 1, they do. For some reason it works to set the step size to a float under 1 and then it will work as an int slider.

Steps to reproduce: Open attached project to see issue

Minimal reproduction project: export_int_issue.zip

definitely annoying. slider should always be visible if the min, max, step values are provided.

[zell2002]

Hey all, whats going on with this then? It's 2024 and Godot 4 is excellent, but why can't I have a Slider for an increment of 1? I think I agree with the above: if a min/max has been set, it should display?

More than anything, clicking the Up/Down button repeatedly to change a number is tedious. Cant seem to click and hold?

[Calinou]

More than anything, clicking the Up/Down button repeatedly to change a number is tedious. Cant seem to click and hold?

EditorSpinSliders with the slider hidden in the editor can be clicked and held, but you need to drag the mouse directly on the number value. In other words, you must start the mouse dragging operation on the number directly, not the arrows.

In projects, this also works on SpinBox nodes, although you must start dragging from the arrow icons and dragging must be performed vertically instead of horizontally. The SpinBox node is also missing support for the Ctrl and Shift modifiers which are used when dragging.

[dog-on-moon]

as a quick+dirty workaround, casting the value out as an int (with a non-1 range step) works in my 4.3.dev5 (and presumably earlier):

@export_range(0.0, 64.0, 0.1) var height: int = 0

this creates an integer slider that behaves as anticipated:

now, this shouldn't be the notation for integer sliders IMO, but this seems useful for anyone who wants them in their project today

[FishOfTheNorthStar]

Anything with ranges specified that can show a slider should show a slider in my opinion. Perhaps there could be an optional property/decorator to the hint_range string, like: 'no_slider', to retain the int format in place now for those that prefer it.

"Visual queue of integer versus float", as mentioned above, may legitimately be of some benefit, but it's nothing compared to 'the docs say this command will add a slider, I added that command and it will not show a slider'. Either the docs need clarified on this or the unexpected behavior needs corrected.

[hsandt]

The thing is that it also behaves the same way for floats (step != 1.0 will show the slider, step = 1.0 will not), I just got this for a float angle and it was really confusing. I thought I had mistyped something or broken the inspector, as the other similar field just below had the slider. In addition, I found about the annotation "hide_slider", so I assumed the slider should be displayed when not using this annotation (that should also answer @FishOfTheNorthStar 's need for a "no_slider" hint).

(btw we could rename the issue title to include "float", I almost missed that issue because I thought it was unrelated)

In this case I added the @export_range + annotations precisely because I wanted a slider to change the angle smoothly (while looking at the result in the scene thx to some custom tool code showing the line corresponding to the angle). So I'd rather have it work out-of-the-box, and otherwise have an extra annotation to force show_slider, like the suggested decimal_style... But since hide_slider already exists, it makes more sense to me to just use that.

So that's for floats. I don't have a strong opinion on int as I haven't stumbled on the issue yet. But I do know that in Unity, I like have that little slider for integer values that are within a specific range like difficulty level between 1 & 10.

And why not have both arrows and sliders if people really fancy them depending on the situation?

EDIT: for now I'll try the workaround of setting step to 2.0... I don't need super precise angles anyway.

[FishOfTheNorthStar]

To clarify, I personally have no need for a 'no slider' hint. That was said for the benefit of other people who apparently don't want the slider to show up. I'm sure they have their reasons.

[benjaminbra]

Hi !

Any news on this ?

It looks like the reason we have this behavior, is because 1.0 is the default value. So the editor seems to define that if there is no step defined by the user, then it will show the arrows.

But if the user is setting a step, then it shows the slider.

So the fix on this should change the default value of the step so that it cannot be confused between the default value and what the user choose to pick.

Maybe set the step to null by default ? And then if the step is null, apply 1 to it and set the hint as "hide_slider".

And if it's to hard to implement due to the complexity of the code. Then maybe always show the slider unless the hint "hide_slider" has been set?

[Calinou]

I don't think this is the reason why the slider is hidden, but either way:

Maybe set the step to null by default ?

The step is a float, and a float can't be null.

[benjaminbra]

I don't think this is the reason why the slider is hidden

Well it's the only reason i can find that could explain this behavior. Because either if it's a float or an int, it'll hide only when the step is 1. If the reason was that the slider doesn't apply on int, then it shouldn't only apply when the step is 1.

The step is a float, and a float can't be null.

Well yeah, that's why a said there might be a "simpler" solution that is never hide the slider, except when the user set the hint to "hide_slider".

[flcoder]

So my work around is to make the step 0.999 and make the type int... I was able to have a slider for values 3 to 9 inclusive. If I set the step to 1.0 then the slider will just disappear. It seems to me the most reasonable thing here would have a @export_slider which works just like range, except it always displays a slider regardless of the step and the step would probably default to 1. or a "show_slider" hint that forces the slider to show.

[benjaminbra]

It seems to me the most reasonable thing here would have a @export_slider which works just like range, except it always displays a slider regardless of the step and the step would probably default to 1. or a "show_slider" hint that forces the slider to show.

Calinou proposed a way to solve this issue : https://github.com/godotengine/godot/pull/95169 If the step is an integer, it will display the integer step arrows, and if the step is a float, then it will display the range slider.

[twoco]

In my case, I want a range to play with the range slider with plausible values. I want to enter decimal values like 10.5 if I want. Or greater, or less. I would not disable the range if 1 is the step with. It should work for all number types, integer as well. A range slider is always possible on a range value (min, max). I see no reason why integer should not work to display a slider.

# Expecting a range slider to all export_range.
@export_range(0.0, 100.0, 1.0, "or_greater", "or_less") var valueFloat := 20.0
@export_range(0, 100, 1, "or_greater", "or_less") var valueInt := 20