ID:133240
 Jan 13 2009, 11:04 pm
|
|
Could there be a variable of some sort to limit the amount of commands processed simultaneously by an individual player? This could be useful in allowing smoother movement, by failing to queue up commands. Any system that ignores movement input until the current move is finished tends to fail, as that's purely guesswork. The time it takes to finish a step tends to vary, and it always ends up lacking any sort of smoothness.
| |
I've tested with a system for a library I'm working on, and it still queues up the commands in such a manner that the step time varies, visually, if nothing else, between 7 and 8 ticks, but not in a pattern that allows me to predict it accurately enough to get rid of it. Allowing a system to limit the amount of movement commands being read at once would be far more preferable.
| |
Popisfizzy wrote:
...and it still queues up the commands in such a manner that the step time varies, visually, if nothing else, between 7 and 8 ticks... This sounds like it may be the problem that I've been attributing to BYOND's map drawing methods. If it is the case that commands aren't being evenly processed each tick; then this may be more of a bug report than a feature request. | |
Popisfizzy wrote:
Could there be a variable of some sort to limit the amount of commands processed simultaneously by an individual player? This could be useful in allowing smoother movement, by failing to queue up commands. Any system that ignores movement input until the current move is finished tends to fail, as that's purely guesswork. The time it takes to finish a step tends to vary, and it always ends up lacking any sort of smoothness. A temporary solution, as far as I can tell, might just be to turn on a variable when movement starts and turn it off when it ends. Then you'll want to halt movement where it starts, the client.Move() procedure. Or, you can use all of the client's directional procedures. | |
CaptFalcon33035 wrote:
A temporary solution, as far as I can tell, might just be to turn on a variable when movement starts and turn it off when it ends. Then you'll want to halt movement where it starts, the client.Move() procedure. Or, you can use all of the client's directional procedures. The problem isn't really starting and stopping it accurately. The problem is the calls not getting delivered in a timely manner. Say you have a 4 second wait time per step, but every 3 ticks the movement command is either discarded, or just not delivered at all. A random step every few steps will be delayed by 1/10th of a second, in visible appearance it sort of makes it look like you're floating through the ocean, where the turfs are moving below you at an unequal speed. EDIT: The problem with that theory is that I still have the problem in BE's movement system. But that system uses a loop to walk the player. | |
A variable to limit the amount of commands a client can send might be helpful. world.tick_lag could be set to a lower value and world.command_lag (or client.command_lag?) could be set to '1'.
The result ought to be a smoother game with much greater FPS, whilst the same amount of messages are sent over the network. This should make faster games possible, without causing lag issues due to the increased network traffic. | |
tick_lag technically limits the amount of commands processed by players per tick, though it slows down the entire game really.
The problem with smoothness shouldn't be due to queued commands, unless you're game is lagging, the commands should be getting canceled by your movement delay/"ignore" system. Movement delays based on guesswork? Step size doesn't vary.
I've built a perfectly functional movement system for BE, the only problem with it is that sometimes BYOND doesn't read they key-ups if multiple things are being input at once; leaving the players to auto-walk.
The movement for IF isn't bad either, though it can lead to some jumpy turns. That might be fixable with pixel_step_size, I haven't done much work with it yet.
If you're referring to the screen/turfs seeming to "slide" behind the player in movement delay systems, I think that's mostly due to BYOND's method of redrawing the map and how quickly it does it.