SC2Mapster

hi, could it be, that there is a restriction for the number of triggers? because suddenly all the trigger didn´t work in the game. so deleted my last trigger and voila it works again. then i created another trigger and again, when the map starts, no trigger is triggered.

does anyone know more about that?

there is an amount of code limit, the real code generated if you click some trigger together

if your at this limit, try to clean your code. for-loops are really bad for example

Yea, theres a limit. Dont know where it is though...

!!! F***************CK !!! jesus, i can´t continue to work on my map :( i read something about 2 MB is the limit. do you know that triggers become smaller? any tricks? i need a lot more than 2 MB :(

EDIT: what do you mean with loops?

do you mean periodic events? do i need more space for lets say i want to spawn zerglings every 5 seconds, but only for 1 minute. is it better to have a periodic trigger which i turn on and of with another trigger? or is it better to have one trigger with spawn zerglings ... wait 5 seconds... spawn zerglings... wait 5 seconds?

a lot? what are you doing?
replace all for loops with while loops
do you use something identical very often?
are there trigger which may be reduced to one if you use funtions+parameters? like 50 identical spawning triggers with only different units

edit:
for i = 1 to 10 do {foo} is bad
while i<= 10 do {foo; i=i+1} is better

a better spawn trigger would be:

function spawn (unittype, unitcount) {
    while i < 12 {
        spawn unittype, count
        wait 5
        i = i+1
    }
}

time elapsed trigger 1 min
        spawn(ling,1)
        wait 60
        spawn(ling,2)
        wait 60
        spawn(hydra,1)
        wait 60
        spawn(ulli,1)
        wait 60

Quote from Forge_User_59026135: Go

if your at this limit, try to clean your code. for-loops are really bad for example

Why is a for-loop bad in relation to the trigger limit?

@Builder_Bob: Go

If I can remember correctly it's because Blizzard have made it so that it can go from 1 to 10 or 10 to 1. That means each for loop has twice the amount of code it would otherwise need. Plus even if it was only one way, the code isn't very efficient. Best thing to do is create your own for loop and use that instead.

It's even worse if you have nested loops.

what is a for loop? do you mean a periodic event or a if, then , else action? well i have 35 waves, each wave has it´s on trigger which is startet with "run-trigger" from the "wave controling trigger". and each wave has it´s own action definition to reate a boss bar indicating the wave. is that bad? shall i create 1 action definition? how do parameters work?

Quote from Forge_User_59026135: Go

@b0ne123: Go

Why is a for-loop bad in relation to the trigger limit?

They're made up of a lot of code. A lot of unnecessary code. I think someone wrote a better for loop here on mapster.

damn, wolf beat me to it. AGAIN.

Also, btw... the 2 MB limit is the compressed one, right? I got 3MB of triggers but its like 174kb compressed.... How the hell does someone reach 2Mb then??? I thought i had many triggers...

Psycho beat me to it now as well, wtf???

Anyway, psycho, a for loop is a loop action. "For each integer" and all similar ones are for loops. "Pick each (player, integer, unit, w/e) are loops as well which arent as inefficient. Then theres the "While" loop i think as well, and probably a lot more.

Quote from TheAlmaity: Go

@Builder_Bob: Go

They're made up of a lot of code. A lot of unnecessary code. I think someone wrote a better for loop here on mapster.

damn, wolf beat me to it. AGAIN.

Also, btw... the 2 MB limit is the compressed one, right? I got 3MB of triggers but its like 174kb compressed.... How the hell does someone reach 2Mb then??? I thought i had many triggers...

Psycho beat me to it now as well, wtf???

Anyway, psycho, a for loop is a loop action. "For each integer" and all similar ones are for loops.

:P

Also, PhychoMC, it's probably best to have one trigger for it all.

I think it was announced for the new Patch 1.3..
They're splitting the stack and heap memory from the script memory. So created objects shouldn't count towards the 2MB limit anymore (or maybe they get their own 2MB).
Since objects probably made up like 90% of the entire memory usage that should be a very nice boost to the script limits.

Quote from TheAlmaity: Go

Also, btw... the 2 MB limit is the compressed one, right? I got 3MB of triggers but its like 174kb compressed....

I think it doesn't count memory usage from variables/objects.

Quote from s3rius: Go

I think it was announced for the new Patch 1.3..
They're splitting the stack and heap memory from the script memory. So created objects shouldn't count towards the 2MB limit anymore (or maybe they get their own 2MB).
Since objects probably made up like three quarters of the entire memory usage that should be a very nice boost to the script limits.

wohooo!
Now if i knew what that meant... lol. I get it. Partially. Can you just give examples of "objects" that took up script memory? Thx.

Quote from 286391 »

a lot? what are you doing?
replace all for loops with while loops
do you use something identical very often?
are there trigger which may be reduced to one if you use funtions+parameters? like 50 identical spawning triggers with only different units edit:
for i = 1 to 10 do {foo} is bad
while i<= 10 do {foo; i=i+1} is better a better spawn trigger would be:

function spawn (unittype, unitcount) {
    while i < 12 {
        spawn unittype, count
        wait 5
        i = i+1
    }
}

time elapsed trigger 1 min
        spawn(ling,1)
        wait 60
        spawn(ling,2)
        wait 60
        spawn(hydra,1)
        wait 60
        spawn(ulli,1)
        wait 60

hm ok thanks for your answers... i hope the tutorial sections here has some good tutorials about triggers. because right now i only use "if, then, else", periodic trigger, "turn of trigger", "run trigger" for linking stuff...

do you think patch 1.3 will help me?

EDIT: i attached the screenshot of my overview manager, can you comment that?

@TheAlmaity: Go

Everytime you create a local variable it takes up memory space on the stack. Integers, strings, structs, etc etc.
Everytime you create a global variable it takes up memory space on the heap.

Basically every variable is an object. Well, most variable types (unit, group, texttag, etc) are only handles and don't use up a lot of space. But large struct arrays are a perfect example of a very memory-eating thing.

@s3rius: Go

Thanks :)

is it better to use no arrays and use variables for each array? is it better to use local variables instead of global? why do you know so much about the trigger editor?

Quote from PsychoMC: Go

is it better to use no arrays and use variables for each array? is it better to use local variables instead of global?

Arrays are simply more variables, no difference. At least no big one. if there is a difference, theyre probably more space efficient (as long as you use all slots)
I think locals are better for when you only need them shortly.

Quote from PsychoMC: Go

why do you know so much about the trigger editor?

Do not question the gods.

@TheAlmaity: Go

prais the trigger editor gods !!!

9000 actions? i bet there is a lot of space to reduce this significantly without any functional influence