How can i explain this, lol. Currently i have a trigger that has 3 "run trigger" in the events. Such as:
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Now my question is. I can compress those 3 "run Triggers" into only 1. so its only.
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Reason i ask is because each 1 of those triggers has 50 events in it, so to compress them would be 1 trigger with 150 events.
Would this improve or do anything to lessen the load of when it fires? or its all water under the same bridge?
Standard Trigger
Events
Local Variables
Conditions
Actions
So i had it as
Events
Local Variables
Conditions
Actions Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Each one of those would run another trigger that had 50 "Actions" a piece. My question was, if i moved all the "Actions" in the 3 "Run Trigger" into only 1 Trigger to make 150 Actions in 1 Trigger instead of 3, Would it improve Game play or will it do basically nothing?
there is no change at all. generally i don't use triggers if there is no event to it (and i will never dynamically add one), just actions
(each trigger is a struc with several variables taking space).
i wonder if these 50 actions cannot be added to one action and just call it 3 times but with different parameters (player?) ?
You'll notice the blizzard campaigns often have triggers without events but I'm not really sure why. I don't think it makes it easier on your computer whatsoever; I think it's more of an organizational thing.
The difference is not organization, it is runtime consideration.
The difference is in the control provided.
Suppose that trigger A starts. It runs and hits an action (which is just a void function call). The original trigger is blocked, since it must wait for the action to complete. Even if the action has a sleep/wait in it, the calling trigger is the same thread and stays blocked.
Now, suppose trigger A starts. It runs and hits a Run Trigger B function call. This is possibly non blocking, based on the parameter of (Wait/Don't Wait). If wait is used, then the behavior is identical to the first situation. But if Don't Wait is used, then Trigger A can resume execution when/if Trigger B sleeps (has any waits called). This is useful to have non blocking behavior of independent actions. If Trigger A, B, C all are running and hit various waits (either hardcoded delays or waiting on UNIQUE resources), then it means the overall execution time of A,B,C is reduced, since B can run while A or C is sleeping, same for A or C.
In the blocking scenario, run time will look something like this.
A Starts -> B Starts/A Pauses -> B sleeps -> B resumes -> C Starts/B Pauses -> C sleeps -> C resumes -> C completes/B Resumes -> B Completes/A Resumes -> A completes
In the non blocking, we get this instead
A Starts -> B Starts/A Pauses -> B sleeps/A resumes -> A Completes/(B can resume/might still be sleeping) -> B resumes -> C starts/B Pauses -> C Sleeps/B Resumes -> B completes/(C can resume/might still be sleeping) -> C Resumes -> C completes
As you can see, the ordering totally changes and becomes VERY dependent on who starts, and how long each trigger sleeps. This is where you can get unpredictable execution order, and if any of these 3 triggers access the same global variable, deadlocks can occur.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
How can i explain this, lol. Currently i have a trigger that has 3 "run trigger" in the events. Such as:
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Now my question is. I can compress those 3 "run Triggers" into only 1. so its only.
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Reason i ask is because each 1 of those triggers has 50 events in it, so to compress them would be 1 trigger with 150 events.
Would this improve or do anything to lessen the load of when it fires? or its all water under the same bridge?
Thanks
actions, events, you confuse me
Assuming you mean actions: There is no difference. I would keep actions in different triggers anyway, just so they are easier to read.
@FunkyUserName
lol sorry about that...
Standard Trigger
Events
Local Variables
Conditions
Actions
So i had it as
Events
Local Variables
Conditions
Actions Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Trigger - Run Trigger (Check Conditions, Don't Wait until it finishes)
Each one of those would run another trigger that had 50 "Actions" a piece. My question was, if i moved all the "Actions" in the 3 "Run Trigger" into only 1 Trigger to make 150 Actions in 1 Trigger instead of 3, Would it improve Game play or will it do basically nothing?
Better? lol.
@SC2UniversalDomination: Go
there is no change at all. generally i don't use triggers if there is no event to it (and i will never dynamically add one), just actions
(each trigger is a struc with several variables taking space).
i wonder if these 50 actions cannot be added to one action and just call it 3 times but with different parameters (player?) ?
i.e. do something player 1
do something player 1
changed to: do something player ParamPlayer
You'll notice the blizzard campaigns often have triggers without events but I'm not really sure why. I don't think it makes it easier on your computer whatsoever; I think it's more of an organizational thing.
<Click Here> To See My Epic Single Player Campaign (LifeForceCampaign.com)
The difference is not organization, it is runtime consideration.
The difference is in the control provided.
Suppose that trigger A starts. It runs and hits an action (which is just a void function call). The original trigger is blocked, since it must wait for the action to complete. Even if the action has a sleep/wait in it, the calling trigger is the same thread and stays blocked.
Now, suppose trigger A starts. It runs and hits a Run Trigger B function call. This is possibly non blocking, based on the parameter of (Wait/Don't Wait). If wait is used, then the behavior is identical to the first situation. But if Don't Wait is used, then Trigger A can resume execution when/if Trigger B sleeps (has any waits called). This is useful to have non blocking behavior of independent actions. If Trigger A, B, C all are running and hit various waits (either hardcoded delays or waiting on UNIQUE resources), then it means the overall execution time of A,B,C is reduced, since B can run while A or C is sleeping, same for A or C.
In the blocking scenario, run time will look something like this.
A Starts -> B Starts/A Pauses -> B sleeps -> B resumes -> C Starts/B Pauses -> C sleeps -> C resumes -> C completes/B Resumes -> B Completes/A Resumes -> A completes
In the non blocking, we get this instead
A Starts -> B Starts/A Pauses -> B sleeps/A resumes -> A Completes/(B can resume/might still be sleeping) -> B resumes -> C starts/B Pauses -> C Sleeps/B Resumes -> B completes/(C can resume/might still be sleeping) -> C Resumes -> C completes
As you can see, the ordering totally changes and becomes VERY dependent on who starts, and how long each trigger sleeps. This is where you can get unpredictable execution order, and if any of these 3 triggers access the same global variable, deadlocks can occur.