Staredit Network

Ok I finished a quickie map (with over 5000 triggers ) to do some lag testing with triggers. Download it here if you're interested:
[center]Mirror 1 (Maplantis)
Mirror 2[/center]


Note that this uses zerglings as the test unit. The other triggers for selecting different tests and hyper triggers are negligible. Note also that this only covers common lag culprits like create, give, remove, kill, move, and order unit actions (and a few others misc ones for good measure).

So far, here's a few interesting conclusions I've made:

• Ordering lots of units to move only creates lag when they're all close together. Lag exponentiates significantly as units get closer to each other with continual ordering.
• Unburrowing lots of units at once (once) as an action by itself doesn't create that big of a lag hit. I've yet to test unburrowing stacked in a single spot or whether simply the AI attempting to spread out the units in doing so isn't what causes lag.
• Moving lots of units around creates HUGE lag, though units failing to move from blockage seems to diminish it (which still lags a bit, though).
• Create unit action (or probably remove unit, or both... I'm unable to tell from my tests) creates pretty hefty lag. Not the worst of the lag culprits, however (surprisingly).
• Any unit trigger actions performed without units creates no noticeable lag.
• Give unit for a mass of units at once, while pretty laggy, lags less than giving units 1 at a time during the same trigger loop for the whole of the same mass.
• I haven't tested these triggers with vision off yet, so I don't know if having vision affects the lag or not.

So what lags the most? It's difficult to tell for sure, but I'd actually say the Move Unit action seems to be the winner. However my test involved multiple move actions spread out in smaller locations instead of just a single one for the Anywhere location, which might be factoring into the results. I'll probably add a new test later on to verify that.

Now realize that my computer only lags on a few of these tests. However I have not tested this in multiplayer, nor had a chance to test with a lower end computer. Therefore if anyone is available with either of these I would welcome any additional observations (especially from online tests). If you have any suggestions also for other tests I should add, please let me know as well.


I'll credit any help I get when I finish compiling the results. Hopefully this should tell us once and for all where trigger lag comes from!

Yeah, sounds logical. The pathing algorithm ignores units that are further away, and once there are lots of units close by, it seems to become pretty excessive.

Moving lots of units seems to start a pathing algorithm for every single of them, or otherwise I can't explain the lag. Would be a lot better if it created a shortest-paths-mapping to one destination point... Well, we can't change that.

Well, I did test online and I seem to agree with you on most of them. However I do think that Moving lots a units around creates HUGE lag, but units failing to move from blockage lags as horribly as the other. It was hard to tell which lags more.

I'll try to think of some other tests later.

I think I already mentioned this but there is a difference between executing actions more than once for the same amount of units vs. a single action on that same amount. What I mean is using 1000 Give Unit actions for one unit each will lag more than a single Give Unit action for 1000 units at once.

Probably is obvious but it is noticeably different so I should point it out.

I'm just curious, what is the point of this? Is there some map you are making where it is critical to be lag-free? (maybe rush 2 )

Making?

Have you played Mechogears? It's been released but playing it only really works if everyone's computer has at least 2.0gz (guesstimate) or something of the sort.

This is the main reason why Tux is awesome. Because as he makes his maps he discovers things that help drive the map making community forward. The maps are nice to, but the main thing is the innovative techniques.

MechnoGears badly needs delaggification.

ADDITION:

Woops posted before me. Yeah I've been meaning to figure out lag once and for all. It's been bugging me for ages in various forms in several of my maps.

Hmmm.... I can't really test, with my cable connection and my 5.2 ghz comp, so I guess we just need to find someone with dial-up and an old 98

The system requirements according to blizzard. Are you shure you have enough strength to run it?

I think Ill test it cause my computer always lagged at the begining preview of rush. Heck it could barely run the map, kinda sad in my oppinion.

Addition:

Here is how I ranked things, if its not on here then its fine.

Anoying: able to move and order but delayed.
Bad: Heavy mouse movement delay, all other actions delayed.
Unplayable: Un able to accuratly move the mouse. No one would play with this much lag!!

Results:
Create 1000 units and set them to Junkyard Dog constantly. (Anoying)
Move 1000 units constantly (actual moves). (Unplayable)
Move 1000 units constantly (blocked moves). (Bad)
Order move 1000 burrowed units once. (Anoying)
Create 1000 units w/ remove constantly. (Unplayable)
Create and give 1000 units 1 at a time (all 1000 of them per trigger loop) constantly. (Unplayable)
Create and kill 1000 units 1 at a time (all in one trigger loop) constantly (Bad-Unplayable) Border line
Create and remove 1000 units 1 at a time (all in one trigger loop) constantly. Tank (Unplayable)
Create 1000 units once and order them to move constantly. (Bad)

hope this helps
One note I made, anything repeated with burrowing lags usually

lol, but notice that that is the minimum, not the maximum, if you don't have that you can't play sc at all, so that it as bad as it gets.

Anyways, nice testing, hmmm, maybe I could use it to fix the lag with the gas in ghentinsville gas rpg, but in that I only have about 200 units being create and killed using hypertriggers with 50 millisecond waits instead of 0.

Maybe someone could also consult the log of his processor/memory usage, might reveal interesting things as well...

Yes that does help. Helps enough at least to confirm what I've suspected.

Here's how I think they go in lag significance:

1. Move unit
2. Create unit
3. Give unit
4. Order unit (varies upon how crowded the units are together)

One peculiar thing I've noticed is the Create 1000 and Kill test delays between each create and kill. Not lag so much as it almost appears the triggers themselves are delayed. Yet the trigger is almost identical to its Remove Unit variation. Either it's an optical illusion brought on by mass killing (like not enough sprites to show additional deaths), a glitch where units killed in mass aren't "cleared" from Starcraft between trigger loops and thus bump the CCMU limit (similar effect, except not an illusion), or else the trigger actions themselves are being canceled or delayed for whatever reason. I suspect the former, though.

i think its cause it causes more animations from the units to happen. I also wonder if you were to disable burrow, if that would cause the move order to lag less, since they would burrow at the end.

5.2 ghz!!!!!! What the hell!!!! How'd you get that? Multiprocessor?

Ya, dual processor, and a good video card

Hmm, perhaps massive amounts of mining could lag as well, since it has to create the mineral chunks, like I have played a map where the players couldnt mine due to ccmu.

I really dought that. Ive never seen massive mining lag, and Ide know my computer does practicly nothing but lag.

Hmm, I played a UMS not too long ago. The creator obviously never even started it in Starcraft. I was able to build like 10 more drones and 6 zerglings, later I managed to add 3 lurkers. I couldn't press any more larvae out of my hatcheries from there on.
My drones were mining, but quite often it wouldn't draw the mineral chunk sprite. It still delivered the (invisible) minerals, though.

Really? When I was playing with my friends over a network with the 1.13f patch they stopped getting minerals, serves em right for making so many cannons. Needless to say, me and my bro won that round

Hmmm.. Only problem with this idea, is how can we stop the lag without making our map worse?

When you have a dual core, you don't just double the speed. ZFor edample if I had a 4 aore mac pro, all running at 3gHz, I wouldn't call that 12gHz. Because half the time only one core is doing the work. Multiple cores are really only usefull when multasking. Starcraft would not take advantage of many cores.

Yes I did try starcraft of a 300mhz 95 computer. It lagged draying the start of a melea map. Let alone a ums map.

300mhz wow thats worst than myn

For me, just clicking on the map caused it to lag.

It does make a difference when you are using all the processors. I do a lot of renders in Blender, so I really like the dual cores.

I have a better idea: Tux buys us all T1 connections . But really, isn't it the graphics that causes the whole lag thing, and not the triggers running? Cant you just somehow place a fog of war or something over the area when loading certain units?

its not peoples connections, so much as peoples computers.