Godot Version
4.3.stable
Question
I was trying to have different screens slide in and out of view by changing their position every frame and then setting their positions to the exact destination coordinates once they're close enough. But for some reason, after a few triggers the scroll method breaks. I found out that it doesn't actually set the position to the destination after running the method multiple times, which is odd because the line where it does so is literally just "position.y = destinationY". I assumed this was some issue with assigning floats. How would I fix this?
Mixing integers and floats requires extra care. What type is destinationY?
1 Like
Thanks for replying! destinationY is a float.
Can you show us the scroll code?
Also: you might find tween() does what you want…
I have it split up between a few methods.
Here is what starts the scroll, which is called via signals containing direction information:
func startScroll(destinationDir: int) -> void:
startY = position.y
destinationY = destinationDir * size.y
moving = true
startY is a float.
In _process(), I have this code:
if moving:
scroll()
if abs(position.y - destinationY) < (100.0 / scrollSpeed):
position.y = destinationY
moving = false
startY = position.y
moving is a global bool. scrollSpeed is an int (I assume) to control the speed, and is currently set to 1000.
And here is the scroll() method that _process() calls:
func scroll() -> void:
var halfwayY = (destinationY + startY) / 2
velocity += (halfwayY - position.y) / (scrollSpeed)
position.y += velocity
velocity is a global float. It starts at 0.
About tween(), I wanted it to speed up until it’s halfway there and then slow down the rest of the way. Does tween() do that?
Is there any possibility that startScroll() is getting called when the position isn’t settled? That is, when moving == true?
1 Like
Your comment made me aware of a different bug, thanks! It was possible for startScroll() to trigger twice, which I fixed with an if not moving: on the first line of startScroll(). However, the previous bug is still happening.
How does it break?
I’m wondering if your velocity is large enough that it overshoots the test in _process(); one frame it’s on one side, the next it’s already past. Your “done” test never evaluates true.
That could be. The bug is that one screen goes in the correct direction, then moves the opposite way twice as far as it’s supposed to, before moving back the right way and stopping in the correct position. This bug might be unrelated to the float not being reassigned, now that I think of it. I just noticed that weird behavior in my testing and thought that was the cause. I’d still like to fix it if I can, though, as even if the bug I can see might not be caused by it, another one could be.