When exporting a float with @export_range I cannot add the “or_greater” extra hint without specifying a step first. The default value for the step is (Editor) > Interface > Inspector > Default Float Step. How can I still use the “or_greater” hint and keep the step defaulting to the default float step as specified above? How can I reference this editor setting from the code?
I think your out of luck on this. Although I don’t see the problem of setting the resolution manually. I would think an exported variable like this would require some resolution control based on its context. Which the project default step could never given context.
I might have one last suggestion, but I’m not at Godot to try.
Can you place the project variable into the parameters, or does it say literals only?
I mean how badly do you need that.
if you really want to get into endless problems their is always EditorInspector and EditorInspectorPlugin.
but I really really don’t recommend going down the scope creep rabbit hole.
it’s been a about a while but I think property_edited signal then _parse_property to deal with changing the thing the user of the plug in is trying to change.
anyway it’s a place to start.
I am being unfair you are only changing one thing perhaps I just tried to do to much and got in over my head.
I don’t know how you can get the default value for this in GDScript. But I think you should at least be able to work around this “constant expression” error by using _get, _set, and _get_property_list instead of @export_range.
And I think it may alternatively be possible using _validate_property?
If I ever make some node that other people will use in the editor in some way or another, it would be pretty great to respect their preferences for float resolution. But it is in no way a priority.
This editor inspector plugin seems promising, but I would think falling back on an editor default value would be built in.
As this is a workaround I’m not marking this as a solution, not until I confirm that there is no “better” way of doing it.
I played around with _get_property_list and it was so hard to get conceptually simple things to work, but it is indeed the way to go around the constant expression error, if the value was a variable.
I was just hoping that there would exist a constant (or at least some other keyword the editor would not complain about) that i could just put in there. Oh well. I guess @export_range appears to be lacking this feature. Not closing this yet, as I did not confirm this is indeed not a core functionality, but thanks for the help.