That's pretty much what i said. The key press functions must be horrifically coded to cause that much lag. Either that or my triggers are. I'd assume the former though. You would think with how versatile those kind of triggers could be, a little more effort would be put into making them function normally.

http://www.sc2mapster.com/assets/wasd-lagless-movement/

I haven't read much of the thread, but here's a link people might want to check. ;o

Interesting, haven't had a chance to check out the map, but if that really is "lagless" it would see to imply that either the camera pitch/yaw functions (doubtable) or the trigonometric functions of sine/cosine/tangent (very plausible) are causing most of the lag. If that's the case I assume someone could write a more efficient custom script for these, or even something as simple as a table look up for values.

I highly doubt it is the camera/pitch/yaw functions though, most camera classes rely on these (or quaternions, or a similar imaginary vector) to prevent gimbal lock. A function to get these values should be nothing more or less than looking for the private field data within the camera class.

I've converted a C++ quicksine/quickcosine formula into my map with WASD controls. I was hoping, if it has been calculated right, and assuming SC2 uses the standard C++/C# math library, these should run anywhere from 8-15 times quicker, and the performance benefit should be noticeable.

Turns out, it is noticeable. Lag spikes seem to be down quite a bit, resulting in an about .5 second response time that is steady (IE: Doesn't seem to lag any more or less). I still need to test it with more people playing to see if multiple users create more lag.

I'm going to look into optimizing this more, see what I can come up with.

That's the cost, I guess.

Updates: http://forums.sc2mapster.com/resources/tutorials/10104-tutorial-lagless-wasd-system-using-data-editor/#p1