Also, adjusting buff duration/ steps might be problematic based on a units movement speed. So you would have to make it different with minor tweaks on every unit.
New update to solve that problem. Set the keyboard repeat delay on your computer as shortest possible and then lower the offest value in the persistant effect (2 to 1) to be more responsive
In milliseconds, how much delay do you think this has, compared to the older ones? Somewhere like 50ms? Where the past WASD was like 100ms?
Well delay for command order for bnet was orginally 250ms, then down to 125ms at the end of beta. If it stays the same, I would saying this delay is 125ms, while the trigger ones is more like 250ms (yep its hard to tell how much the delay was, but easy to tell it exist)
Diagnols aren't a very good solution, can't you just change the angle of the unit like +5 or -5 depending on a/d and have a/d move the unit as you would with a?
Or I guess better yet to use q/e and for those motions and a/d only for strafing left or right. OR switch that since people would probably use a/d more for turning then they would normally use a straf.
Quote from LordFelco:
I was just laying in bed moments ago, pondering how the hell one of us here nerds could solve the laggy, laggy problem of the key press event.
Am I correct in saying that pressing hotkeys for spells and abilities does not cause the same lag? If so...
Isn't there a way to make abilities run triggers? We could set up spells on the command card for moving in certain directions, with hotkeys of W, A, S, D. Each button would run the trigger that is otherwise activated by the key pressing event.
Keep in mind that I probably don't know what the hell I'm talking about, as last night was an awesome party.
----
!$%^, I thought I had something.
I added "Disable Ability" to the behaviors, so that while moving down, one could not hit "down".
You could still hold the key, of course, and continue moving in the same direction.
Diagonal movement is then possible, BUT you have to hit (start pressing) both keys at the same time.
Hit W+D, move up-right in an effed-up back-and-forth (like programer said, could probly be resolved with a combine validator).
Hold W, move up. Still holding W, hit D, moves up :(
Why will command card detect both buttons if I hit them at the same time, but not one after the other? :(< Maybe there's a sneaky trick around this?
Also, just curious, undoubtedly stupid question, but there's absolutely nothing for a data based mouselook, right?
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.
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 exsist.
This one is definitely less laggy than with current trigger version but not meant to get rid of the delay. The delay might improve a bit by not having to go through trigger validation. (Lag and delay are different). And yes the trigger systems generate quite a lot of traffic for Key Pressed events
Its fine if you don't use it. Its just a tutorial for exploring the data editor anyway. I hope for more creative use of the data editior by sharing it out.
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?
The theory is that triggers only execute about ever 0.05 seconds or so while data actions execute as soon as the server receives the message. So a data editor only approach eliminates any potential delay in between the server receiving the input and running the triggers to process the input. At best this eliminates 50ms on the client and 50ms on the server, so under the best case your effective latency is reduced by 100ms. (
I'm skeptical of how much difference there actually is but I haven't tried it and progammer is one of the more trustworthy people around so I'll take his word that the gains are noticable.
I will say that the perception that normal ladder games don't lag as much as WASD-based custom maps is 99% psychological. Controlling movement by giving orders has a very, very different feel than assuming direct control of a unit even when latency is identical. In fact, I can testify from experience that just moving from a keyboard-based movement system to a mouse-based movement system while still using triggers GREATLY reduces the feel of lag, even though the input latency is identical.
I can say based on the conception that melee (ladder) competitive game on battlenet does not experience too much delay issues compared to wasd map present. (why the hell would they release a network system for a RTS game if such latency is unacceptable) And all of the unit abilities is done via data editor. I might have made a mistake that causing it more delay then normal melee abilities should but that's the goal to aim for. If pro-gamers can spam 300 APM consistently and their unit is responding well. Why not ?
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.
Well I got 8 way working consistently but I used a hybrid of two systems. Four buttons, 8x of everything else using combined validators but I didn't use any of the behavior removal methods and instead used a good ol key-up event to remove the four cardinal direction behaviors. This method worked perfectly in the editor test doc and I'm pretty confident that movement felt more responsive in battle net as well, but yah there is no concrete way to measure it. My gamble is that perhaps while key-down is broadcast to all clients and synced perhaps key-up is ignored for the usually insignificant thing that it is, also that people care more about how fast their unit starts moving rather then stops. I can say that movement responses were higher then my mouse clicks (the non-bouncing laser in the clip below is just a straight call to a persistent effect so it ignores any issue order conflicts).
Demo clip of single user in battle net performance:
As you can see I really rough-shot it, no button icons and didn't bother hiding the direction behaviors so they're cycling rapidly on the status card and making that annoying sound.
Further ED: I switched the same map back over to trigger based key down/key up...and it felt the same trying it again on battle net, darn.
My gamble is that perhaps while key-down is broadcast to all clients and synced perhaps key-up is ignored for the usually insignificant thing that it is
Key up is not as important as it does not give you the perception of responsiveness. They're just there to remove behavior, stop your unit while you're not pressing. How fast they react to key down is a problem
I followed this to the letter twice, and got the same result. When i go to command card, I set command type to ability command, ability to move right / left/ up / down, but i cannot change Ability command to anything but move up. It works, so I'm not sure if this is important but I'd appreciate your input.
Just create a demo map where you move one unit directly with abilities, while at the same time a trigger catches the key presses and moves a second unit parallel to the first. Then add some slots and upload it on bnet, so everyone can test and compare the different systems effectively.
Bonuspoints for a video of said map with multiple players testing at the same time.
In milliseconds, how much delay do you think this has, compared to the older ones? Somewhere like 50ms? Where the past WASD was like 100ms?
@TECGhost: Go
this isnt warcraft 3 this is sc2. get over it. This is in fact very flexible, you just have to take the time to understand it
New update to solve that problem. Set the keyboard repeat delay on your computer as shortest possible and then lower the offest value in the persistant effect (2 to 1) to be more responsive
Well delay for command order for bnet was orginally 250ms, then down to 125ms at the end of beta. If it stays the same, I would saying this delay is 125ms, while the trigger ones is more like 250ms (yep its hard to tell how much the delay was, but easy to tell it exist)
Nice work!!!
btw When would "2 keys pressed at same time" be an issue? only for diagonal movement mostly? well then cant we set "Q", "E", etc as diagonal movement?
Sure, read the 1st solution for 8 ways system. I have trouble with the 2nd solution only
@progammer: Go
Diagnols aren't a very good solution, can't you just change the angle of the unit like +5 or -5 depending on a/d and have a/d move the unit as you would with a?
Or I guess better yet to use q/e and for those motions and a/d only for strafing left or right. OR switch that since people would probably use a/d more for turning then they would normally use a straf.
@progammer:
Posted on Aug 14th...
Quote from LordFelco:
I was just laying in bed moments ago, pondering how the hell one of us here nerds could solve the laggy, laggy problem of the key press event.
Am I correct in saying that pressing hotkeys for spells and abilities does not cause the same lag? If so...
Isn't there a way to make abilities run triggers? We could set up spells on the command card for moving in certain directions, with hotkeys of W, A, S, D. Each button would run the trigger that is otherwise activated by the key pressing event.
Keep in mind that I probably don't know what the hell I'm talking about, as last night was an awesome party.
----
!$%^, I thought I had something.
I added "Disable Ability" to the behaviors, so that while moving down, one could not hit "down".
You could still hold the key, of course, and continue moving in the same direction.
Diagonal movement is then possible, BUT you have to hit (start pressing) both keys at the same time.
Hit W+D, move up-right in an effed-up back-and-forth (like programer said, could probly be resolved with a combine validator).
Hold W, move up. Still holding W, hit D, moves up :(
Why will command card detect both buttons if I hit them at the same time, but not one after the other? :(< Maybe there's a sneaky trick around this?
Also, just curious, undoubtedly stupid question, but there's absolutely nothing for a data based mouselook, right?
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.
This one is definitely less laggy than with current trigger version but not meant to get rid of the delay. The delay might improve a bit by not having to go through trigger validation. (Lag and delay are different). And yes the trigger systems generate quite a lot of traffic for Key Pressed events
Its fine if you don't use it. Its just a tutorial for exploring the data editor anyway. I hope for more creative use of the data editior by sharing it out.
@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?
The theory is that triggers only execute about ever 0.05 seconds or so while data actions execute as soon as the server receives the message. So a data editor only approach eliminates any potential delay in between the server receiving the input and running the triggers to process the input. At best this eliminates 50ms on the client and 50ms on the server, so under the best case your effective latency is reduced by 100ms. (
I'm skeptical of how much difference there actually is but I haven't tried it and progammer is one of the more trustworthy people around so I'll take his word that the gains are noticable.
I will say that the perception that normal ladder games don't lag as much as WASD-based custom maps is 99% psychological. Controlling movement by giving orders has a very, very different feel than assuming direct control of a unit even when latency is identical. In fact, I can testify from experience that just moving from a keyboard-based movement system to a mouse-based movement system while still using triggers GREATLY reduces the feel of lag, even though the input latency is identical.
@Kalekin: Go
I can say based on the conception that melee (ladder) competitive game on battlenet does not experience too much delay issues compared to wasd map present. (why the hell would they release a network system for a RTS game if such latency is unacceptable) And all of the unit abilities is done via data editor. I might have made a mistake that causing it more delay then normal melee abilities should but that's the goal to aim for. If pro-gamers can spam 300 APM consistently and their unit is responding well. Why not ?
@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.
Well I got 8 way working consistently but I used a hybrid of two systems. Four buttons, 8x of everything else using combined validators but I didn't use any of the behavior removal methods and instead used a good ol key-up event to remove the four cardinal direction behaviors. This method worked perfectly in the editor test doc and I'm pretty confident that movement felt more responsive in battle net as well, but yah there is no concrete way to measure it. My gamble is that perhaps while key-down is broadcast to all clients and synced perhaps key-up is ignored for the usually insignificant thing that it is, also that people care more about how fast their unit starts moving rather then stops. I can say that movement responses were higher then my mouse clicks (the non-bouncing laser in the clip below is just a straight call to a persistent effect so it ignores any issue order conflicts).
Demo clip of single user in battle net performance:
As you can see I really rough-shot it, no button icons and didn't bother hiding the direction behaviors so they're cycling rapidly on the status card and making that annoying sound.
Further ED: I switched the same map back over to trigger based key down/key up...and it felt the same trying it again on battle net, darn.
@BumpInTheNight: Go
Key up is not as important as it does not give you the perception of responsiveness. They're just there to remove behavior, stop your unit while you're not pressing. How fast they react to key down is a problem
@progammer: Go
I followed this to the letter twice, and got the same result. When i go to command card, I set command type to ability command, ability to move right / left/ up / down, but i cannot change Ability command to anything but move up. It works, so I'm not sure if this is important but I'd appreciate your input.
ps thanks for the cool system.
Just create a demo map where you move one unit directly with abilities, while at the same time a trigger catches the key presses and moves a second unit parallel to the first. Then add some slots and upload it on bnet, so everyone can test and compare the different systems effectively. Bonuspoints for a video of said map with multiple players testing at the same time.
Nvm what I said... can't delete this post can I?
this system is faster and it is not just psycological. i would say aroun 150-200 ms faster if not more