Report, edit, etc...Posted by Mp)MinigameEast on 2005-04-13 at 23:04:43
let me refrase that. can a wait trigger interfer another wait trigger?
becuace on my other new map it sometimes interfer. i activate a trigger with wait in it and then ill choose another thing to activate the second trigger at the same time. and the first one has 8 seconds left and i activate the second one that has 15 seconds. will these add up 23 seconds on wait or will it just run threw?
becuace on my other new map it sometimes interfer. i activate a trigger with wait in it and then ill choose another thing to activate the second trigger at the same time. and the first one has 8 seconds left and i activate the second one that has 15 seconds. will these add up 23 seconds on wait or will it just run threw?
Report, edit, etc...Posted by chuiu on 2005-04-13 at 23:12:59
Yes, and they always interfere with other wait triggers. The first one fires, then they second waits untill the first one is over to fire. Thats pretty much how it works.
Your best bet is to use death counters, which is why everyone is always talking about them. Go check out the tutorials.
Your best bet is to use death counters, which is why everyone is always talking about them. Go check out the tutorials.
Report, edit, etc...Posted by LegacyWeapon on 2005-04-13 at 23:18:30
Wait blocks work because waits cause the SC engine to check all triggers to see if their conditions are fulfilled (and runs them if they are).
The problem would be if you have a wait (so it checks all the triggers), and finds a trigger and runs it (but it has a wait in it!), so then it hits that wait and searches through all the triggers again, and resolves in order of whichever one was run last.
Simpler terms:
1) First trigger runs
2) Hits a wait (checks all triggers for conditions to be fulfilled)
3) Finds another trigger that can be run
4) Hits the 2nd trigger's wait (checks all again)
5a) If none are found, finishes the 2nd trigger's wait, then finishes the 1st trigger's wait.
5b) If a wait is found, process continues.
The engine checks for triggers that have their conditions fulfilled before the wait actually starts "waiting" in a sense.
This is also the reason why hyper triggers work.
The problem would be if you have a wait (so it checks all the triggers), and finds a trigger and runs it (but it has a wait in it!), so then it hits that wait and searches through all the triggers again, and resolves in order of whichever one was run last.
Simpler terms:
1) First trigger runs
2) Hits a wait (checks all triggers for conditions to be fulfilled)
3) Finds another trigger that can be run
4) Hits the 2nd trigger's wait (checks all again)
5a) If none are found, finishes the 2nd trigger's wait, then finishes the 1st trigger's wait.
5b) If a wait is found, process continues.
The engine checks for triggers that have their conditions fulfilled before the wait actually starts "waiting" in a sense.
This is also the reason why hyper triggers work.
Report, edit, etc...Posted by (U)Bolt_Head on 2005-04-14 at 04:00:29
Not the way i would say it but I sounds right to me.
Report, edit, etc...Posted by Heimdal on 2005-04-14 at 14:09:45
I was under the impression that the check for other pending triggers happens when the wait finishes. I'd test it myself but I'm on remote desktop at the moment.
Report, edit, etc...Posted by chuiu on 2005-04-14 at 21:48:44
I'm pretty sure that's how Legacy described it. He didn't word it very well though. (yet he's the Tutorial Keeper, go figure 
)
)Report, edit, etc...Posted by LegacyWeapon on 2005-04-15 at 00:20:07
Sorry if there's any confusion
The way I "figured" this out was by reading hyper trigger conceptuals, reading Bolt's posts on hyper triggers and waits, and other people's posts.
Let me reword it a bit:
When a SC engine hits a wait in the trigger actions, before it initiates (starts) the wait, it will check through all the triggers to see if their conditions are fulfilled (and if so, runs the triggers before doing (running) the wait).
This poses a problem when there are many waits running at the same time.
But this is also the reason why hyper triggers work.
The way I "figured" this out was by reading hyper trigger conceptuals, reading Bolt's posts on hyper triggers and waits, and other people's posts.
Let me reword it a bit:
When a SC engine hits a wait in the trigger actions, before it initiates (starts) the wait, it will check through all the triggers to see if their conditions are fulfilled (and if so, runs the triggers before doing (running) the wait).
This poses a problem when there are many waits running at the same time.
But this is also the reason why hyper triggers work.
Report, edit, etc...Posted by Heimdal on 2005-04-15 at 02:21:33
QUOTE(chuiu_os @ Apr 14 2005, 08:48 PM)
I'm pretty sure that's how Legacy described it. He didn't word it very well though. (yet he's the Tutorial Keeper, go figure )
[right][snapback]187933[/snapback][/right]
No, he said that SC checks for pending triggers before it starts "waiting." I thought it did so at the end of the wait, but it turns out he's right.)[right][snapback]187933[/snapback][/right]
Report, edit, etc...Posted by (U)Bolt_Head on 2005-04-15 at 04:33:50
Yeah, it checks before it starts 'waiting' 
Of course it runs the actions and everything in order. Not like it checks all the conditions then exicutes them, it does it one at a time.
Of course it runs the actions and everything in order. Not like it checks all the conditions then exicutes them, it does it one at a time.
Report, edit, etc...Posted by chuiu on 2005-04-15 at 06:15:45
My bad, I read your post wrong Heimdal.