So I just remembered something back in one of my C# programming classes. When making multiple conditions (&&) for your IF statements, it's best to put the least likely to be true condition first, because if it is found false, it's smart enough to not even bother finishing the IF statement to see if the other conditions are true, thus saving time/cpu.
I was wondering if something as primitive as triggers follow the same principle? Like If I have a trigger with 2 conditions, and one is "commands 1 firebat"(which is almost always) and the second is "Has suffered exactly 33 deaths of zergling"(which is almost never). If I reverse the order, then most of the time only 1 condition will be checked every trigger cycle, instead of 2.
Do you think sc is this efficient? Heinnerman is probably the only person who could answer this. If not, I have an awkward idea for a test map, and it would be nice to have discovered something new (How to Shave-Off Map Lag) that I can credit to myself.
Pretty sure triggers work the same way. I have no evidence though, just assuming they do since the triggers are translated into code, and code works that way.
I always put switch conditions that are more likely than not false as the first condition if I can.
None.
This was discussed a while back, yes, placing the least likely to be true condition first will use less processing power than having to run through several true conditions before discovering the entire thing to be false.
None.
Cool. I'm glad I haven't been wasting my time being a freak about those little things.
How was it proven?
Also, this need to be added to
this under "Map Lag" The fact that it actually wasn't mentioned there was the biggest reason I thought this hadn't been decided on yet.
Falkoner is correct. It stops checking the conditions once one of them returns false. While it doesn't make a real difference in maps with medium and lower amounts of triggers, it is absolutely crucial when you are, for instance, at 15k.
Most likely to return false shouldn't be the only factor, however. The bring condition has much more work attached to it than reading, for example, a binary switch, which is why I always put switches at the top of the list.
None.
Will do. It wasn't there because I can't empty 100% of my mapmaking knowledge all at one time
None.
wow this is gonna be great.
None.
This can be proven through changing the order of a crashing EUD condition, I found this out inadvertently.
None.
Now we need Heinermann and Farty's compressor to organize conditions in the best order. It would be interesting to see how much, if at all, it lags. (15 bring conditions with 1 switch at bottom, times 15k).
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
While it doesn't make a real difference in maps with medium and lower amounts of triggers, it is absolutely crucial when you are, for instance, at 15k.
My map's at 17k with its share of bring conditions but there's never any lag that's the map's fault. It has no give actions whatsoever, but we're talking about difference in condition ordering/checking, so I wouldn't worry too much about it.I thought lines, where does it tell you trigger count in SCMDraft2 anyway?
Post has been edited 2 time(s), last time on Dec 2 2009, 1:14 am by yoonkwun.
None.
Now we need Heinermann and Farty's compressor to organize conditions in the best order. It would be interesting to see how much, if at all, it lags. (15 bring conditions with 1 switch at bottom, times 15k).
What does that have to do with compression?
And I can further confirm this based on my experiences...
TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB -
topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig -
topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!
It would be interesting to see how much, if at all, it lags. (15 bring conditions with 1 switch at bottom, times 15k).
Here. 20,000 triggers plus four hyper triggers.
Attachments:
None.
Hm, so if the map is expected to be ~500k, would it be worth it to reorganize conditions to reduce lag?
None.
What kind of map are you making...
None.
What exactly are you doing that takes that many triggers?
None.
What exactly are you doing that takes that many triggers?
I dunno, things just add up ><. It's a pretty complex map.
It doesn't matter though, will I notice a difference reorganizing 500kb worth of triggers?
None.
Hm, so if the map is expected to be ~500k, would it be worth it to reorganize conditions to reduce lag?
Unless you're using EUD/EPDs there is no reason for it to get that high. But to answer your question, yes, it would be worth it.
Edit: Loool. 500kb worth is much much different than 500,000 triggers.
None.
What exactly are you doing that takes that many triggers?
I dunno, things just add up ><. It's a pretty complex map.
It doesn't matter though, will I notice a difference reorganizing 500kb worth of triggers?
It's only 500kb? That's a long ways away from 500,000 triggers. Triggers on my map I posted had only 20,004 triggers and is less than 800kb
None.
Hm, so if the map is expected to be ~500k, would it be worth it to reorganize conditions to reduce lag?
Unless you're using EUD/EPDs there is no reason for it to get that high. But to answer your question, yes, it would be worth it.
Edit: Loool. 500kb worth is much much different than 500,000 triggers.
Ehhh, I never meant you guys to think I was making 500,000 triggers lol. Indeed the map is going to be 500kb on completion - it is ~450 now and I should definitely reorganize them? Alright I have some prime suspects for reorganization needing.
None.
