« first day (3329 days earlier)      last day (1698 days later) » 

7:53 PM
@trollingchar Doesnt that mean that i will get a dead spot where the user cant move the player at all?
 
user4704
@abobakrdy Yes. You generally want that, even if it is just a very small dead zone.
 
user4704
Otherwise you can, in the general sense, never arrive at the target because you "circle the drain:" on frame N, you're not at the target, so you move and overshoot the target, so on frame N +1 you're not at the target, so you move and overshoot the target, etc.
 
user4704
And you jitter forever.
 
user4704
If you can solve that without gameplay ramification by clipping the speed or movement displacement to exactly arrive on the target, you'll usually want a dead zone just to prevent jitter from accidental light mouse movement, etc.
 
^
 
8:15 PM
Sounds about right, but cant i just move the player if its above a certain radius without using the inverselerp function?
 
user4704
Oh, yes.
 
user4704
You don't necessarily need the lerp, particularly if you want to interpret the movement as "move in this direction" instead of "move to here"
 
user4704
Often the math or at least functional result ends up looking the same anyway, but.
 
8:54 PM
Yeah, lerp didnt make that much difference in this case. However, im far from getting it the way i want: see comparison
 
user4704
9:17 PM
It's hard to tell from that video, the framerate is a bit low, but it looks like the way the "desired movement" works is by moving the player in the direction indicated by the mouse (perhaps by projecting the mouse position to the ground plane and getting the vector from the character origin to that projected point).
 
user4704
It looks like there's a dead zone around the player where that won't be true, but also while the mouse is in the dead zone, it doesn't stop the player -- they just keep going in the direction they were going?
 
user4704
To me that seems most obvious at the very start of the video, where the character is moving up, and the mouse moves slowly down across the character... they keep moving up, but as soon as the mouse gets a certain distance from the character, the character snaps around
 
9:34 PM
Ah, i finally figured it out!
Ive been stuck on this for a day, lol. I was using a method which moves the player to a target position, by a specific distance per call. In order to get this desired movement, i had to use a movement method which moves the player in the direction its facing instead. This combined with a dead zone, that only allows the user to navigate if they are above it, takes away the jittery movement. And when the player is inside this dead zone, the player will just keep moving in its direction.
 
Greetings!
Is the problem gone?
 
10:02 PM
Indeed. Now it seems like a kind of obvious solution, like "Why didnt i just think of that right away?", lol.
 
lol.
I'm currently busy refactoring timers in my game. Now I store their time in variables and updates decrease it. What's wrong? The approach when there is global time and all timers are assigned once and compared to it seems better to me.
Goodbye everyone and good luck with your projects
 
 
1 hour later…
11:28 PM
Doesnt make sense that update decreases the assigned timers. thx, good luck to you to
 

« first day (3329 days earlier)      last day (1698 days later) »