Range: Only use the snapped value if it is different enough from the entered value #110176
+7
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Sorry, I deleted my question because I felt it was not the place for general questions about Godot's behaviour. I just didn't want to spam the issue. 😅 |
Repiteo
added
the
cherrypick:4.5
KoBeWi
reviewed
Sep 19, 2025
Member
|
How does it fix the issue? I see the same behavior when I follow the steps. |
aaronfranke
removed
the
cherrypick:4.5
aaronfranke
force-pushed
the
range-snap
branch
from
126d096 to
bbc0382
Compare
Member
Poke @aaronfranke |
aaronfranke
force-pushed
the
range-snap
branch
from
bbc0382 to
49800e4
Compare
Member
Author
|
@KoBeWi was correct, it wasn't working right in all cases, and the problem was due to the relative tolerance as he pointed out. Since we are using fixed-precision (R128), the tolerance would go lower than where the fixed-precision float "bottoms out". Changing this to a fixed value instead of a relative one seems to work in all cases now. MRP: Bug.zip Video of the fix compared to 4.5.1-stable: oh_snap.mp4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #109838 (not a regression fix this time, this PR is actually an improvement over what Godot has ever had before)
@jan-kapoli commented (but deleted their comment?) asking why we are snapping at all. Well, the reason why is because this is the behavior of Range. However, that still raises a good point. If the value is already good, we shouldn't need to snap it. This PR checks if the value is approximately equal to the snapped value, and uses the original value. This now works correctly even for values and step sizes down to
1e-7:Snapping will still occur if the value is different enough. For example, with a step size of
0.0000001, if you enter0.000000101, this gets converted to9.999999999994822e-08instead of0.0000001, but0.0000001gets preserved as the closest possible float to0.0000001(and therefore serialized as1e-7).The behavior in this PR may be slightly worse if you don't trust the user's input, allowing the value to be up to
1e-14away from the snapped value rather than force-snapping to within1e-15or1e-16of the best value. However, I think this is a very minor problem (only slightly worse than the imprecisiondoublealready provides), and has the benefit that if you do trust the user's input and expect that the value the user entered is probably already good, this helps.