ID:2857266
 
Hey guys. I was fiddling with some old game source of mine here that was created based on a 15fps server tick (it's a really old source). I've tried to increase the world fps to 60, to have a smoother and more pleasant gameplay according to 2023 standards, but, all the projectiles, are going insanely fast (probably 4x times faster). I've tried some approaches, like, putting a sleep proc inside it's Move proc but, this way I'll need to put this sleep line on all procs of all projectiles movement, it will be a pain. Also, could the client.fps lower than world fps fix this, or will it break stuff even more?
As a general rule you definitely don't want client.fps to be lower than world.fps. It's the client where you want the faster ticks, not the server. The point of separating the two was to allow smoother animation and gliding on the client while still letting the server perform at a slower tick to handle larger player counts.

The reason your projectiles are going fast has to be based on whatever code is responsible for moving them, which we would have to see.

The most likely explanation for the change is that either your projectiles have a loop where they manually call one of the step procs or Move(), or they have a walk() call. If pixel movement is enabled for the game, then your simplest option is to tie the projectile's step_size to world.tick_lag.

obj/projectile/fireball
// before (at 15 fps)
step_size = 8

// after
step_size = 120 / world.fps

The idea is you multiply by 15 (the old world.fps) to get pixels per second, and then divide by the new world.fps to get pixels per tick. That then future-proofs your code because then you can change world.fps however you like.