After much thought and experimentation I have created a new way to Trigger movement that dose not use any Periodic Events, Player Angles or Camera Yaw. I have though about using the unit command card but that will not work due to the fact that I am unaware how to register 2 keys pressed simultaneously. So here is a tutorial on how yourself can use this new movement system I have created. It may not be 100% Lagless due to the fact that its currently not possible. However I find that while using these controls with the game speed setup for slow, normal or fast its possible to come really close.
First off you have to setup some Variables to define controls
I have set up the Variables as arrays. I haven't set up the units as an array because i simply forgot, They can be setup as arrays as well.
Next Set the Unit Variables to the units you wish to control. Make sure the unit has the Move and Stop Ability otherwise it won't work.
After you have that done its now time to create movement. In Short this system is very simple. By pressing which way the unit goes, the unit is ordered to move 100 spaces in that direction (May seem like a lot but its to prevent the unit from stopping in short distances). Upon release of that key the unit is ordered to stop. Fantastically Simple.
After adding a lot more to that simple method you should get triggers like these.(I thought posting pictures to be a better explanation)
For Left and its release
For Right and its release
For Up and its release
For Down and its Release
Here is an overview of the triggers.(Don't worry about space, I was experimenting with jumping)
The Camera triggers set the camera to the unit at the start of the map.
You can easily add up to 16 players for wasd controls, it just takes awhile to copy and paste all those triggers.(You can see my map is setup for 2)
Hope this helps out greatly. You are welcome to use my map and this however you want, just make sure to give credit when due :D
use "any player" in the triggers and than link to "triggering player" if you need to save the variables.
will save loads of space. less triggers = less lag.
What if the map is not empty. If there's a wall, the unit is going to be ordered to go beyond the wall and may not going to where you want because of the path finding.
What if the map is not empty. If there's a wall, the unit is going to be ordered to go beyond the wall and may not going to where you want because of the path finding.
Never thought of that, after adding cliffs and some wall doodads found out that your right. I Changed the mover to cliff jumper for my Hero, this corrected pathing and unit doesn't cliff jump as well keeping it within bounds.
use "any player" in the triggers and than link to "triggering player" if you need to save the variables. will save loads of space. less triggers = less lag.
I find that even if triggering player is grayed out it usually still works. Just remember that triggering player returns a number from 1 to 16 or whatever, but indexes start at zero, so you will need to often use (triggeringPlayer - 1).
Ah ha, it works, got only 8 triggers working for 16 players instead of the tons that would of been used. Uploading to bnet and testing now. Thanks for the idea
I'd be very surprised if this solution is lagless.
With several players it'll still be slower than my granny, just because it uses the Key Press events. And there's no way around it.
Also, I think you're overestimating the impact of things like Camera Yaw (or functions in general), loops or timers. First of all these things don't create lag. The only thing they could do is to shortly freeze weak computers. And even that would happen only in the most extreme cases (if it could happen at all, due to the execution limit).
Galaxy is pretty gosh darn fast (compared to JASS2 lol). You could have ten 0.001 second timers in your map doing a ton of things and you still wouldn't notice the slightest thing, even with 12 players and a dog playing the map.
It is definitely a going more easy on your CPU than other movement systems do, I'll give you that. But whether it's really worth it? I doubt it.
Its not completely lagless, but its responsive enough to make games very playable, I have tested this current version on bnet and it works great. I understand the events and camera angles but it just seemed a bit much to me. Its defiantly worth a shot trying, I have great success with this so far.
I'd be very surprised if this solution is lagless.
With several players it'll still be slower than my granny, just because it uses the Key Press events. And there's no way around it.
Also, I think you're overestimating the impact of things like Camera Yaw (or functions in general), loops or timers. First of all these things don't create lag. The only thing they could do is to shortly freeze weak computers. And even that would happen only in the most extreme cases (if it could happen at all, due to the execution limit).
Galaxy is pretty gosh darn fast (compared to JASS2 lol). You could have ten 0.001 second timers in your map doing a ton of things and you still wouldn't notice the slightest thing, even with 12 players and a dog playing the map.
It is definitely a going more easy on your CPU than other movement systems do, I'll give you that. But whether it's really worth it? I doubt it.
Uhh, you can have ten 0.0000000000000000000000000000000000001 second timers simply because the minimum trigger interval is 0.0625, and all those timers will default to 0.0625.
The 0.001 timer was just a simplification. I know about the 1/16th limit, but I don't want to be splitting hair right now.
I just mean to say that you can execute a kiloton of stuff without loss of performance.
You said you tried to on battlenet - with how many players was that? I probably doesn't lag that much when you're testing alone, but in a full-house game it'll probably suffer the same fate as all the other systems.
Logic demands it being like that. Because if it's the event that causes lag it doesn't matter what the actions are. As long as you use the same events, you will have delay in the same cases.
If you're in EU then we can gather some people and test it out, but judging from the time you've posted you probably aren't - so can you try rounding up like 3-5 other people and do a test?
It was tested with 2 and was running nicely. I'm on the us server. Ill get a big group and test it with as many players asap. I wanted to test it with jackolas's suggestion with triggering players and it works great. When i attempt to upload it to bnet for a test run it fails with a -validation working set instance fail- . My best guess is its being cause from using the triggering player action with it being greyed out. For now ill resort back to my original system unit I find a fix. Ill also look at putting a video together comparing the the old movement I learned from a tutorial here and this one now comparing responsiveness. As for a full house of 16 its possible to suffer the same fate but I have faith for it to work :D
EDIT - Fixed Map not uploading to Bnet, just resorted to a backup save.
I'm not too convinced that this way will provide even a noticable reduction in the lag. It's really the input part that causes the lag right now and not the loops, right? As far as I got there's still the same amount of input stuff going on here as in other systems?
After testing the map with 3 other players there was no loss in responsiveness. I would like to test with even more players but don't know that many people. If anyone is able to help do a stress test please send a pm or add me on the us server (wazoom.590) I greatly appreciate any testers and will return the favor.
Yeah, I saw that as well, but I'm going to go ahead and try anyway. If it works then, huzzah, if it gets lagged up at large amounts of players then at least I know I can still create and awesome 4 player wasd style map which has playable movement. But, Yes because of that key pressed event there is no way around it that creates perfect movement. I didn't say this was a perfect movement system but one that is more responsive than previous systems I have used. I'm just trying to do something for this great community of awesome mapper (who are again awesome) by creating something everyone could use.
The 0.001 timer was just a simplification. I know about the 1/16th limit, but I don't want to be splitting hair right now.
I just mean to say that you can execute a kiloton of stuff without loss of performance.
It's true, this is 2010 and it's extremely hard to do anything CPU intensive, but the point is that the extra latency tends to come from the average 32 MS of lag sitting on top of the 125 MS Battle.net minimum latency.
This is why I sincerely doubt this system is an improvement at all over a system that uses a looping timer with a low interval. Even events get the trigger delay from fitting into the 16 execution slots a second (I don't even know what Blizzard was thinking), so timer-driven systems will be as screwed as event-driven systems.
There's a hack/workaround to get 32 executions a second, and that's the only conceivable way I know of to make a reduced lag WASD system. And even that will only change the additional latency range from 0-62.5 to 0-31.25 MS, shaving off an average of 16 MS.
In the end, no matter what you do you're still going to be dealing with a 1/8th of a second response time. That may not seem bad, but consider that pings as low as 40 are standard for FPS games, which have lag compensation on top of that. Starcraft 2 has no lag compensation system.
Just a note, your movement system's turned into diablo where you run faster diagonally than forwards or backwards. Ideally it's one movement unit in any direction. Right now your diagonals go 1.4. Just a note.
No need to reinvent the wheel. You were aiming to perfect a circle and what you seemed to have come up with is an octagon. The only culprit behind lag in a good WASD system is the "Key Pressed" event, which you still use.
After much thought and experimentation I have created a new way to Trigger movement that dose not use any Periodic Events, Player Angles or Camera Yaw. I have though about using the unit command card but that will not work due to the fact that I am unaware how to register 2 keys pressed simultaneously. So here is a tutorial on how yourself can use this new movement system I have created. It may not be 100% Lagless due to the fact that its currently not possible. However I find that while using these controls with the game speed setup for slow, normal or fast its possible to come really close.
Here is a link to the map if you want to skip anything http://www.sc2mapster.com/assets/wasd-lagless-movement/"Lag less" (see what i did there :D)
Now for the good stuff
First off you have to setup some Variables to define controls
I have set up the Variables as arrays. I haven't set up the units as an array because i simply forgot, They can be setup as arrays as well.
Next Set the Unit Variables to the units you wish to control. Make sure the unit has the Move and Stop Ability otherwise it won't work.
After you have that done its now time to create movement. In Short this system is very simple. By pressing which way the unit goes, the unit is ordered to move 100 spaces in that direction (May seem like a lot but its to prevent the unit from stopping in short distances). Upon release of that key the unit is ordered to stop. Fantastically Simple.
After adding a lot more to that simple method you should get triggers like these.(I thought posting pictures to be a better explanation)
For Left and its release
For Right and its release
For Up and its release
For Down and its Release
Here is an overview of the triggers.(Don't worry about space, I was experimenting with jumping) The Camera triggers set the camera to the unit at the start of the map.
You can easily add up to 16 players for wasd controls, it just takes awhile to copy and paste all those triggers.(You can see my map is setup for 2) Hope this helps out greatly. You are welcome to use my map and this however you want, just make sure to give credit when due :D
-wazoom
you don't have to copy every trigger.
use "any player" in the triggers and than link to "triggering player" if you need to save the variables. will save loads of space. less triggers = less lag.
example For press Right:
this saves about 150 triggers in a 16 player map
What if the map is not empty. If there's a wall, the unit is going to be ordered to go beyond the wall and may not going to where you want because of the path finding.
so far i can see the whole system is kinda messy. think here are way better ways to do it
Never thought of that, after adding cliffs and some wall doodads found out that your right. I Changed the mover to cliff jumper for my Hero, this corrected pathing and unit doesn't cliff jump as well keeping it within bounds.
Again never thought of that. It defiantly helps and saves tons of triggering. Going to try implementing that now. Thanks
Edit- Got it working with triggering player, Cant get it to upload to bnet for some reason, says -validation working set instance fail-
I find that even if triggering player is grayed out it usually still works. Just remember that triggering player returns a number from 1 to 16 or whatever, but indexes start at zero, so you will need to often use (triggeringPlayer - 1).
Ah ha, it works, got only 8 triggers working for 16 players instead of the tons that would of been used. Uploading to bnet and testing now. Thanks for the idea
I'd be very surprised if this solution is lagless.
With several players it'll still be slower than my granny, just because it uses the Key Press events. And there's no way around it.
Also, I think you're overestimating the impact of things like Camera Yaw (or functions in general), loops or timers. First of all these things don't create lag. The only thing they could do is to shortly freeze weak computers. And even that would happen only in the most extreme cases (if it could happen at all, due to the execution limit).
Galaxy is pretty gosh darn fast (compared to JASS2 lol). You could have ten 0.001 second timers in your map doing a ton of things and you still wouldn't notice the slightest thing, even with 12 players and a dog playing the map.
It is definitely a going more easy on your CPU than other movement systems do, I'll give you that. But whether it's really worth it? I doubt it.
Its not completely lagless, but its responsive enough to make games very playable, I have tested this current version on bnet and it works great. I understand the events and camera angles but it just seemed a bit much to me. Its defiantly worth a shot trying, I have great success with this so far.
Uhh, you can have ten 0.0000000000000000000000000000000000001 second timers simply because the minimum trigger interval is 0.0625, and all those timers will default to 0.0625.
@Fellius: Go
The 0.001 timer was just a simplification. I know about the 1/16th limit, but I don't want to be splitting hair right now.
I just mean to say that you can execute a kiloton of stuff without loss of performance.
@wazoom: Go
You said you tried to on battlenet - with how many players was that? I probably doesn't lag that much when you're testing alone, but in a full-house game it'll probably suffer the same fate as all the other systems.
Logic demands it being like that. Because if it's the event that causes lag it doesn't matter what the actions are. As long as you use the same events, you will have delay in the same cases.
If you're in EU then we can gather some people and test it out, but judging from the time you've posted you probably aren't - so can you try rounding up like 3-5 other people and do a test?
@ s3rius
It was tested with 2 and was running nicely. I'm on the us server. Ill get a big group and test it with as many players asap. I wanted to test it with jackolas's suggestion with triggering players and it works great. When i attempt to upload it to bnet for a test run it fails with a -validation working set instance fail- . My best guess is its being cause from using the triggering player action with it being greyed out. For now ill resort back to my original system unit I find a fix. Ill also look at putting a video together comparing the the old movement I learned from a tutorial here and this one now comparing responsiveness. As for a full house of 16 its possible to suffer the same fate but I have faith for it to work :D
EDIT - Fixed Map not uploading to Bnet, just resorted to a backup save.
I'm not too convinced that this way will provide even a noticable reduction in the lag. It's really the input part that causes the lag right now and not the loops, right? As far as I got there's still the same amount of input stuff going on here as in other systems?
After testing the map with 3 other players there was no loss in responsiveness. I would like to test with even more players but don't know that many people. If anyone is able to help do a stress test please send a pm or add me on the us server (wazoom.590) I greatly appreciate any testers and will return the favor.
"Only register for this event when you absolutely need it, as it will generate network traffic from all players for every button they press."
Based on that statement for the event, it is the event that causes the lag as well as gets worse with higher amounts of players.
Yeah, I saw that as well, but I'm going to go ahead and try anyway. If it works then, huzzah, if it gets lagged up at large amounts of players then at least I know I can still create and awesome 4 player wasd style map which has playable movement. But, Yes because of that key pressed event there is no way around it that creates perfect movement. I didn't say this was a perfect movement system but one that is more responsive than previous systems I have used. I'm just trying to do something for this great community of awesome mapper (who are again awesome) by creating something everyone could use.
It's true, this is 2010 and it's extremely hard to do anything CPU intensive, but the point is that the extra latency tends to come from the average 32 MS of lag sitting on top of the 125 MS Battle.net minimum latency.
This is why I sincerely doubt this system is an improvement at all over a system that uses a looping timer with a low interval. Even events get the trigger delay from fitting into the 16 execution slots a second (I don't even know what Blizzard was thinking), so timer-driven systems will be as screwed as event-driven systems.
There's a hack/workaround to get 32 executions a second, and that's the only conceivable way I know of to make a reduced lag WASD system. And even that will only change the additional latency range from 0-62.5 to 0-31.25 MS, shaving off an average of 16 MS.
In the end, no matter what you do you're still going to be dealing with a 1/8th of a second response time. That may not seem bad, but consider that pings as low as 40 are standard for FPS games, which have lag compensation on top of that. Starcraft 2 has no lag compensation system.
@wazoom: Go
Just a note, your movement system's turned into diablo where you run faster diagonally than forwards or backwards. Ideally it's one movement unit in any direction. Right now your diagonals go 1.4. Just a note.
No need to reinvent the wheel. You were aiming to perfect a circle and what you seemed to have come up with is an octagon. The only culprit behind lag in a good WASD system is the "Key Pressed" event, which you still use.
You should take a look at my WASD Library & Short Tutorial, which are 3 months old now (And still great): http://forums.sc2mapster.com/development/tutorials/2342-tutorial-8-way-wasd-movement/
@rrowland: Go
Essentially you've just bundled all of the key press checks down or up into one? That actually help?