Not sure whether I have already asked this, but is there a way to create a WASD movement without lag? I've seen stuff like that on other maps but did not figure out how exactly it worked. Help!

I think it uses periodic events and no use of a fixed camera behind a unit (camera updates = huge lag).
{But maybe the camera lags can be disabled by disabling the replay recording... I don't know, just a guess}

You don't use triggers to set the direction of the unit - you use them to order a unit to move at an angle. Setting direction at very short intervals can 'lag' the unit in question and it'll move jerkily and eventually stop and jerkily rotate.

So, no 'make unit face x'. Just 'order unit to move to x'. On a related note, ESDF > WASD and my Mech Combat map might be a nice example for some things. http://www.staredit.net/topic/10916/ . I have basic controls, physics, etc and a lot of it is commented and the rest mostly understandable.

If this isn't what you mean, elaborate. What's lagging? What triggers are you doing? Etc.

Post has been edited 1 time(s), last time on Aug 2 2010, 10:15 pm by Centreri.

I never used a camera, it's top down view.
W to move, A and D to turn (S to move backwards).

Event: key is pressed
if: pressed key == "W"
-> Make Point face angle == facing of unit, make the same point offset by 1 or 2 (doesn't really matter), order unit to that point.

For A and D I would simply make the same but subtract like 10-15 degrees (or add) to the point's facing to make it more left... get it?
I made a slightly different system before, completly with ordering the unit (no degrees subtracting) and it lagged as the FPS seems to be slowed.


Actually, a better question: does a wait block of 1 game second in that trigger avoid the lag?
Keep in mind that the keys are pressed DOWN so not a "was pressed" event.

Err...

The best way to make sure you're doing the pressing right is to make a variable for each key. When one presses down on that key, that variable is true; when one presses up, it's false. When that variable is true, you execute the whatever.

If you have that already, also try this:
Set refresh time to .05 seconds
The make point face angle looks right but sounds odd. I believe it's something closer to "Order unit to move to 'position of unit offset by two towards (direction unit is facing)"
Turning would then be "Order unit to move to 'position of unit offset by two towards (direction unit is facing +- 10)"
I don't exactly remember how I handled both of those simultaneously; Actually, I think I had the E (forward) simply increase acceleration, and the acceleration would increase/decrease unit movement speed.

I also tried that key pressed = change variable as the only action. Did not work either, though I noticed that I could do this and this might work:
Event: key pressed
actions: do actions, disable current trigger, wait 1 second, enable current trigger
This will ensure to run this trigger only once every second which drastically should decrease the lag

... What do you mean did not work? The variables would be set?

No, you're really screwing up something, or you have a VERY bad computer. I had a .05 interval for physics calculations for slope, for variable resets, etc. A ton of stuff. For main mech, for multiple shots... There WAS some possible slowdown, but not obvious enough that I went to whine about it here. What you're doing here is so much less intensive than what I did that I really doubt that there's an actual 'happening too often' problem.

Instead of using key detection triggers, which lag, use unit hotkeys, which don't.

That sucks as players can also use Grid Hotkeys which ignored map's hotkeys.
Cent, would mind creating a test map for me? ;( (and attach it)

I mind, as I currently do not have an editor. I do, however, have MECH COMBAT, linked above in my first post here, which successfully accomplishes key-based movement. I have the only complicated part commented, for chrissakes. Take a look, because you're not describing what you're doing here well enough for me to magically solve your problem. The trigger that handles this, I believe, is called 'Periodic'. I stuck pretty much everything in there.

Post has been edited 2 time(s), last time on Aug 3 2010, 12:46 am by Centreri.

...Just make the data-hotkeys for movement's layout correspond to grid layout. You're trying to use wasd anyways.

Again, WASD sucks. ESDF is the way to go. WASD has QERFZXC near it; ESDF has WAZXCVGRQT near it. If you're going for multiple other abilities or want to expand on it later, go ESDF.

Seriously, the caps lock can get in the way with WASD. <_<

You can still use esdf with what I posted! (I actually messed up and put wasd in the spot of esdf. )

Could you elaborate on this a little bit? I searched around but only found this post:

Would that imply that just changing the hotkeys to the key that you want to detect, and leaving the trigger event as "Player presses x down" would remove the lag? Would you have to use the "Detect Button" instead of "Detect Key"? Or would you have to create a trigger looking for the actual ability being cast, and do the movement actions with regards to those?

The latter. Make them abilities, detect when they're cast.

There is a right grid as well, it would be like YUIOP and so on for them.

How would one go about detecting a key-up with this? I assume a key-down would be to detect if the ability is either being casted or in queue.

Yeah, no key-up. But I don't think you should worry; I didn't notice any significant delay or lag when doing it the 'key down' trigger way.

Well the reason I'm curious is when you start to support multiple players it really does start to get noticeable. I created a test map with 8 players that are handled this way, just to see what kind of performance I could get. With two human players and six computer players (no AI, mind you, but they were technically present in the game) the lag would end up somewhere between .5 - 1.5 seconds (roughly) or more. There's is none with only one player though (untested on battle.net).

I've been looking into alternatives for this, this one seems viable. I was thinking perhaps it'd be possible to work with dummy behaviors to see which state of movement would be active (up, down, left, right), but i haven't seem to been able to come up with a method to detect key-ups in the same fashion.

Really? Hrrm. That's fairly retarded. When it's faster to take a roundabout path like making dummy abilities just to detect button presses..

Lols.