An interesting theory, and to my knowledge the server does indeed run game logic at a specific interval, once every 1/32th of a second, though using triggers we will use only every second frame (1/16th). However I see no reason as to why the data editor would work it's magic outside of these frames when the rest of editor's functionality is so closely tied to it.
PS. Even the number used for the built in latency (125ms or 1/16th of a second) is a result of this.
PPS. Again, I would like this system to pan out but without some sort of side by side comparison it's all just *feeling*.
That last section of your post is my point exactly. Everyone is comparing the feeling of WASD latency to that of controlling units in a melee game. I would stake money on the fact that the trigger based input systems experience the same delay in responses as mouse issued orders. But they don't *feel* the same?
You hit the nail on the head. With direct movement from keyboard input your expectation is that the unit responds instantly. In a melee game you have no such expectation from the units you are giving orders to. It's the expectation of instant feedback that creates the illusion that trigger based WASD is less responsive than mouse input and I would argue that it is progammers same expectation of more effecient data based system that is causing the feeling of improved responsiveness.
I understand you believe it to be less laggy, but why? What advantage does a data table based WASD system have over a trigger one that reduces the delay in responses? And how do we know, beyond our belief that it *feels* less laggy, that it is in fact faster?
Don't get me wrong, I would really like to find a more responsive system than triggers, however I do not believe one can exist. Yes, delay and latency are different but in this case our former is a result of the latter. We can not reduce the network latency, so how can we look to reduce the delay?
I don't understand the theory behind why this is meant to be less laggy than a trigger based system. The issue with any keystroke based movement system is the latency between the commands issued by the client and the response from the server. Both trigger keystrokes and the UI command card are subject to the same latency issue and, unless you are suggesting that a trigger system generates ludicrous amounts of network traffic, I can't see the advantage of using the data editor.
What I would really like to see is a video with a map using both systems side by side illustrating the differences between response times, if they even exist.
@BumpInTheNight: Go
Very good video. As expected I see no benefit with regards to response times from the data driven movement.
@RileyStarcraft: Go
An interesting theory, and to my knowledge the server does indeed run game logic at a specific interval, once every 1/32th of a second, though using triggers we will use only every second frame (1/16th). However I see no reason as to why the data editor would work it's magic outside of these frames when the rest of editor's functionality is so closely tied to it.
PS. Even the number used for the built in latency (125ms or 1/16th of a second) is a result of this.
PPS. Again, I would like this system to pan out but without some sort of side by side comparison it's all just *feeling*.
@RileyStarcraft: Go
That last section of your post is my point exactly. Everyone is comparing the feeling of WASD latency to that of controlling units in a melee game. I would stake money on the fact that the trigger based input systems experience the same delay in responses as mouse issued orders. But they don't *feel* the same?
You hit the nail on the head. With direct movement from keyboard input your expectation is that the unit responds instantly. In a melee game you have no such expectation from the units you are giving orders to. It's the expectation of instant feedback that creates the illusion that trigger based WASD is less responsive than mouse input and I would argue that it is progammers same expectation of more effecient data based system that is causing the feeling of improved responsiveness.
@progammer: Go
I understand you believe it to be less laggy, but why? What advantage does a data table based WASD system have over a trigger one that reduces the delay in responses? And how do we know, beyond our belief that it *feels* less laggy, that it is in fact faster?
Don't get me wrong, I would really like to find a more responsive system than triggers, however I do not believe one can exist. Yes, delay and latency are different but in this case our former is a result of the latter. We can not reduce the network latency, so how can we look to reduce the delay?
I don't understand the theory behind why this is meant to be less laggy than a trigger based system. The issue with any keystroke based movement system is the latency between the commands issued by the client and the response from the server. Both trigger keystrokes and the UI command card are subject to the same latency issue and, unless you are suggesting that a trigger system generates ludicrous amounts of network traffic, I can't see the advantage of using the data editor.
What I would really like to see is a video with a map using both systems side by side illustrating the differences between response times, if they even exist.