Hi. I had alot of problems with my current map with lag, not due to connection issues. I've talked with alot of people that have told me some interesting things about certain triggers being laggier than others. I'm wondering if somebody can post for me a bunch of trigger types that are known to cause lag. I know:

Running many triggers under pure hypers will cause lag (if many are being used at once).
Mass sprites will cause lag. (Though, is it possible to disable the doodad state for a large number of units and enable them later such as in an rpg to reduce lag?)
Somebody has told me putting your setting/clearing switches on the top of your actions can lesses lag. (Is this true?)

If somebody can tell me anything that would be helpful please do, or any lag prevention techniques.

Thank you so much! -al

Use the search before posting.
http://www.staredit.net/topic/3374/

Mass sprites does not necessarily cause lag, it only causes it if it's masses of animated sprites.

Clearing and setting switches causes no lag whatsoever, and putting them in a different spot changes nothing.

The things that cause lag are those that involve AI, path-finding takes a lot of processing power, and path-finding when there are a bunch of units in the way who are also moving takes even more processing power, so masses of moving units causes the most lag, but generally the second most lag causing thing is anything graphics related, or in other words, related to units.

Any triggers that are simply modifying variables and things unseen by the player will cause almost no lag at all, as they are doing simple functions, and not involving anything processor intensive, like graphics.

I've just carried out a number of tests to find out how simple conditions/actions affect lag. There are some interesing results. The pack with test maps is attached to the post. Look the description of the test map in the first two triggers.

Probably much location invalidations may also cause lag (invalidations could be performed in conditions!).

I think move location action is on the third place after graphics (see test 240kTrgExecsLagTest6.scx).

I'm not agree with you on the one thing:
I can prove using a location ivalidation effect that conditions are checked from top to bottom until one of them is false or all are true. Thus, placeing more lightweight and more probable to be false conditions on top will reduce the lag (because other conditions would not be checked). I must admit this effect is only noticeable if you have thousands of triggers. That way just dont bother if you're not makeing something as epic as Astrogears!

Also, SCMD Text Trigger editor wont allow 50 000 triggers But accepting 30 000, so the current border is somewhere between these numbers =)

Download lag tests pack

Every trigger condition and action will cause "lag", or use runtime resources.

IMO the laggiest trigger actions would probably be(in the following order)
1. Anything to do with units excluding deaths and score. [Creation of units includes finding an empty index, and creating 336 bytes of unit information, specifying the sprite, image, and iscript information takes a lot of work as well(finding the GRP, running the iscript init). Killing and removing is the opposite.]
2. Transmission/PlayWAV. [PlayWAV alone needs to extract a file from the MPQ archive and play it back, transmission displays portrait, text, and everything else]
3. Show portrait. [This actually loads the SMK file from the MPQ archive on every call]
4. Move location. [You're dealing with scanning for the leftmost unit in a location and modifying 4 fields, maintaining the original locatioin size, also checks to make sure the location doesn't go off the map.]

Afaik sc can only play 8 wavs at a time anyway. So I'd assume that you can't make a map lag with playing wavs just because only 8 of these actions are by far not enough to occupy modern computers to a noticeable degree.

I was speaking about switches, action order does not matter, if one runs, they all run, I admit that conditions can be ordered in order to create less lag, however this is so negligible it'll only help if you have a truly MASSIVE amount of triggers, more than any editor can work with.

And I'm not so sure that the Move Location is such a laggy action, I remember in Tuxlar's tests, he had it move location a few thousand times and no lag was created whatsoever. I mean, all it's doing is finding the unit's location, and then modifying 4 variables, how could it cause much lag?

Then I'm sorry, I've misunderstood you.

This is do negligible but text editors nowadays will allow you to have and handle so many triggers. I personally think that 5000 triggers executeing for each of 8 players is enough to notice the effect.

Well, few thousands is not enough itself to lag, but if you have a few thousands move locations executing for each of 8 players this could be a 50% of the lag. Move location may cause two invalidations: the first for the location where the unit is searching and the second is for the moved location itself. As far as I know each location invalidation is scanning through all units on the map (imagine you have a thousand units) and then narrowing results to the particular location.

And if it does then SC should arrange it properly.

Post has been edited 2 time(s), last time on Feb 18 2009, 9:48 am by Wormer.

A switch in the condition would be less laggy than a bring and even a death count, right?

Moving many units to a location where they cannot be moved to, because other units block the whole area, causes much lag, too.

I actually think that the Death Count and the Switch are about the same, maybe the switch is faster, being a bool in a smaller table, however I doubt it.

You'd be surprised

There were virtually no units on the map to scan through, which is a very large determining factor.

Order action is also a big lag determinant.

I believe they both cause equal (the smallest) lag, because both operations deal with the same machine level commands with integer numbers. Also I think switches are represented as bytes or even integers, and not bits.

By the way moveing units to a location which is out of map bounds causes no lag (very small).

Less, but not none. I've seen many maps lag solely because of excessive use of this.