-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make floating-point values in the inspector more permissive #10068
Comments
There's already a proposal tracking this: #3524 |
There's a PR for this but it's not been taken a look at for a bit, maybe by next minor release? |
One thing I'm not sure about for If nothing about I can see two ways about this:
For infinite values, I think the solution is much clearer: show their actual values unconditionally rather than showing them as 0 (the current behavior godotengine/godot#88006). I would also say that instead of I'm currently working on implementing this proposal for personal use (so far I've implemented the fields described, added hints, and poorly updated |
I'm mostly done with the interesting part of implementing this proposal; currently I have the following things left:
I would also have to update the range hint of every single float field in Godot's codebase (around 875 fields) for these features to be of any use. I plan on doing this, but I'm not sure whether it should be in the same pull request or separate. What I have so far is available at https://github.com/MrEgggga/godot/tree/permissive-range. (So far I've been making most of my commits fairly small, but according to the contributing guidelines in the documentation it seems like it would be best to squish everything into one commit.) One issue I ran into when implementing this was that fields which are stored as
I'll probably have to rewrite pretty much all of this if I want to account for single-precision One issue that wasn't a problem before (because it was covered up by a bigger problem) but might come up in the future is that values that are too small (around 5e-15 for double-precision fields and 5e-7 for single-precision) will be rounded to zero (see godotengine/godot#93768). This probably isn't that big a deal (for quite a while it's been impossible to input float values less than 5e-4 and have them stick), but I personally think that the inspector should use scientific notation for large and small values, both for readability and to ensure that information is not lost when |
Describe the project you are working on
A 2D physics-based puzzle platformer
Describe the problem or limitation you are having in your project
I constantly run into issues when changing floating-point values in the inspector:
I mention the actual bugs to point out that these sort of stem from the over-restrictiveness of the
Range
class and the Godot inspector. However, they should probably be handled separately from this proposal.Disallowing NaN and Infinity (godotengine/godot#81076) fixed a number of issues where the editor or games crashed when certain fields were set to infinite values, but in my opinion this was a stopgap solution and doesn't really do anything for cases when these fields could be set to NaN via script. In general, I don't see any reason for editing floating points to be this restrictive by default; generally the developer of a game knows what they're trying to do more than the editor does (they might be using NaN in one of their scripts as a special value because Godot currently has no easily-editable way of making optional types in the inspector; they might need a number to be accurate to more than a thousandth; etc.), and making things less restrictive by default in the editor doesn't make things worse for use cases which need the more restrictive behavior; the fields which cause huge problems when set to non-finite values can keep the behavior from godotengine/godot#81076.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add options in the
Range
class which can remove some of these restrictions, and enable these by default for exported variables (but not forRange
nodes in games).Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
allow_infinite
with default valuefalse
to theRange
class that allows for non-finite values.allow_finer
with default valuefalse
to theRange
class that prevents rounding of values entered by typing into the field (using the slider inSpinBox
or the up/down arrows would still round things to the step value).true
for float properties with no hint, andfalse
by default with properties with hints, similar toallow_greater
andallow_lesser
. Add hintsor_infinite
,or_finer
and ideally add these to existing properties as appropriate (but that can be done separately, after the features needed are implemented).If this enhancement will not be used often, can it be worked around with a few lines of script?
If a specific floating point value is needed that cannot be entered in the inspector (e.g. NaN, 0.12345, pi, 0), it is possible to edit the scene in an external editor and write the exact value in there; however, if the field is touched in the inspector (e.g. by selecting it and pressing Enter) it'll often be rounded again. Exact values can also be set in scripts or as the default export value, but these are kind of inflexible and cumbersome.
Is there a reason why this should be core and not an add-on in the asset library?
This is about changing some core behavior in the editor and is less of a "new feature" than a "fix."
The text was updated successfully, but these errors were encountered: