ID:747484
 
Keywords: fps, gliding, lag
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Currently, the gliding effect will still work with projects that still want to use tile-based movement.

However, if you increase the world.fps, everything in the game will now move much faster. For example, changing from 10 FPS to 30 FPS causes all the movements to happen 3 times as often. This is strange, because the animation speed of the icons remains the same regardless of FPS. This is also terrible if you're using the default movement macros (i.e. NORTH+REP) that send a command to the server every frame a key is held, because it slows the network speed significantly.

A solution to this is to remove the default movement macros, and instead, only send key-up and key-down events. Then, you use a loop that constantly checks every frame which keys are pressed and has a cool-down so that the player moves slower, and still glides.

This usually works, but I've noticed when hosted online, the gliding stops happening. I'm not sure if that's due for a separate bug report, because the gliding works offline and it still works online for 30 seconds or so.

Now, the purpose of increasing the FPS is because the input becomes more responsive, and the processing is faster (assuming the computer CPU can handle it).

What I'm requesting is a built-in feature that automatically limits the speed at which movables can move, when in tile-based mode. For example, you can already set the glide_size, but it doesn't matter if it still moves one tile per frame, because of a high FPS. Maybe another variable glide_delay could exist, which would be the number of server ticks between movements.
The problem is that glide_size, like many other built-in numeric variables, doesn't accept decimals; only integers. Decimal values allow you to move slower than one pixel per tick in pixel movement as well as your issue.
In response to Kaiochao
Kaiochao wrote:
The problem is that glide_size, like many other built-in numeric variables, doesn't accept decimals; only integers. Decimal values allow you to move slower than one pixel per tick in pixel movement as well as your issue.

Does glide_size actually limit the movement speed? Like, if you reduce it, does the Move() proc actually get called less often?
I was under the impression that wasn't true.
If you're having gliding interruptions with movement, and throttling movement speed, one simple option is to simply alter the code you're using to throttle the speed; there really isn't any reason gliding should stop if this is done correctly.

Throttling movement speed in tile mode is a very widespread need but it's also 1) easy, and 2) different in many different movement systems. It's better to do this in soft code.
In response to Lummox JR
Can you give an example of doing it correctly? Because I must be doing something wrong.

I will point out that it only stops gliding after 30 or so seconds, and only with many players logged in.

EDIT: More specifically, 30 seconds after server start-up. If I reboot, the gliding works again for about 30 seconds.
If you're saying all gliding stops entirely, then that's due to something using step_x/y and/or non-tile bounds. There'd have to be something in your world that would cause that; it could also be something in a savefile, so I'd be sure to remove step_x/y and bounds vars from the savefile in Read() before calling ..() to account for that.
No, my game doesn't have those vars even used anywhere. Everything is default. (And I've read countless posts with you recommending that same thing.)

I don't know if gliding stops entirely. The animation seems to glitch a bit and show a frame of animation, but it's more-or-less a single, discrete jump. That's why I thought it was an issue with lag.


EDIT: If I don't get a response by today, I'm going to assume this is a bug and file a bug report.
Yes, glide_size does not have to be a divisor of icon_size. It can be any (whole) value you like.

The big questions would be: 1) After this starts happening, does it stop happening again once the number of players goes down? 2) Does it only show up on your system, or on theirs as well?

If this only shows up for you, it would make sense if it's because you're hosting in DS and map drawing is just taking too much time to complete. The solution there is not to host in DS.

If this shows up for all users, then something is disabling the gliding, and that definitely means the step or bounds have been altered. This could be as simple as having once experimented with it and then changing your mind, while some savefiles might still have the old info--hence my recommendation to cleanse those on load. If you've doctored the Move() proc at all to take additional arguments, that too would be a code issue.

At present I don't have enough info to fully understand what you're seeing, and it sounds like you don't either, so a bug report would be premature.
In response to Lummox JR
Okay, I think you're right about a bug report being premature.

It's being hosted on a Linux shell (latest build: 493.1116). It seems to happen at different times for different players, and it doesn't go away when the player count goes down. Though, a lower player count does seem to delay the effect quite a bit.

It's really not the step_size/x/y or bounds being altered. I am quite sure of that. I never experimented with that, because I never wanted anything other than a tile-based game for this particular project. (I only recently changed from pixel_step_size to glide_size when I saw that it was the new standard.)

I increased the framerate, because the animations stay the same speed and because input is so much more responsive.