I would not recommend using periodic triggers. I believe the more events that are triggering, the more problems arise. I think it is safe to use loops inside triggers with waits. For example, to spawn units every .25 seconds, I believe it is safer to use a while loop that runs 25 times, rather than a periodic event.
I made a work around for the problem in my TD. The first image is what I originally used to control movement. The disabled action is the move order, which I no longer use.
With nothing attacking, this works perfectly with 400 mobs at a time (that's the highest I've tested.) When units were attacked, triggers begin to no longer fire. This is likely because I had triggers which run when a unit was attacked. I have since removed these.
The system I used for movement might look complicated, enough so that I could have screwed the logic up, but I did not. I know this because if my system for indexing the movement regions is incorrect, it will order them to move to the wrong region, or give me an array-index-out-of-bounds error. It did neither. They just stopped.
Well, the point of this post was not to decide what is more efficient, but merely to point out that this problem exists at all. It took me a week of scrutinizing over everything (the unit properties (was their radius causing them to get stuck?), the trigger logic, pathing) I looked at many different things before I even thought to consider the trigger might not be working.
I even implemented many, many anti-stuck and anti-attack triggers, thinking the problem was with units trying to path around each other, and getting confused.
This exasperated the problem, because my anti-stuck / anti-attack triggers used attack events to detect whether they were stuck. It took me a very long time to determine it was the events themselves.
I am going to post a tutorial on how I corrected this problem, and how to prevent blocking / stuck in Tower Defenses in general shortly.
I generally avoid using "Wait" commands in a trigger that can be called while it's still in a previous run. Does this not cause any issues like it did with the original SC editor?
Also, Vexal, it looks like you're updating unit move commands once they reach their next destination. Is there a reason to do that instead of queuing move commands when they're originally spawned?
My original reason was because if someone blocked, it would screw everything in the queue up. I have recently switched to a system that combines queuing the orders at the spawn, as well as using move regions to keep track of how far the units have traveled. I will detail this in the tutorial I post.
Using waits in triggers is safe because all variables are local. In Warcraft 3, it was not safe in GUI because loop variables / event response handles were global, and relied on the fact that only one trigger could execute at a time (but not true if it used a wait).
yea as vexal said, Waits are fine, providing you use Local variables (
that way it cant be overwritten) , Nothing is wrong with a wait.
The main issue is the Events i believe.
Either way ... if you change a couple things to the way I out lined it ... it will work 100% of the time... unless the unit is not actually dying.....
And then your players wont have to click a respawn button... which is what your post on the other site said you wanted to avoid....
also I personally avoid putting waits in any trigger that can be run multiple times while the one is currently running..... that trigger can be run lots and lots on top of itself...
I generally call a sub function to handle the heavy lifting.... doing this also helps me debug stuff.....
From looking at your list of triggers.... you have alot of trigger based spells......
that could also be the problem.... any one of those effecting the damaged / dying unit could be preventing your unit from actually dying....
we would have to take a comb through the entire thing...
and your really not pleasant enough to do that for......
@SouLCarveRR: Go
I would not recommend using periodic triggers. I believe the more events that are triggering, the more problems arise. I think it is safe to use loops inside triggers with waits. For example, to spawn units every .25 seconds, I believe it is safer to use a while loop that runs 25 times, rather than a periodic event.
I made a work around for the problem in my TD. The first image is what I originally used to control movement. The disabled action is the move order, which I no longer use.
With nothing attacking, this works perfectly with 400 mobs at a time (that's the highest I've tested.) When units were attacked, triggers begin to no longer fire. This is likely because I had triggers which run when a unit was attacked. I have since removed these.
The system I used for movement might look complicated, enough so that I could have screwed the logic up, but I did not. I know this because if my system for indexing the movement regions is incorrect, it will order them to move to the wrong region, or give me an array-index-out-of-bounds error. It did neither. They just stopped.
well having 1 periodic trigger run once every second.... is like.... way less demanding then
10 triggering being run every time a unit dies/attacks etc.... try to avoid "any unit" events and your code will run smoother
periodics are only a problem if you try to run them faster then 1 second
Well, the point of this post was not to decide what is more efficient, but merely to point out that this problem exists at all. It took me a week of scrutinizing over everything (the unit properties (was their radius causing them to get stuck?), the trigger logic, pathing) I looked at many different things before I even thought to consider the trigger might not be working.
I even implemented many, many anti-stuck and anti-attack triggers, thinking the problem was with units trying to path around each other, and getting confused.
This exasperated the problem, because my anti-stuck / anti-attack triggers used attack events to detect whether they were stuck. It took me a very long time to determine it was the events themselves.
I am going to post a tutorial on how I corrected this problem, and how to prevent blocking / stuck in Tower Defenses in general shortly.
I generally avoid using "Wait" commands in a trigger that can be called while it's still in a previous run. Does this not cause any issues like it did with the original SC editor?
Also, Vexal, it looks like you're updating unit move commands once they reach their next destination. Is there a reason to do that instead of queuing move commands when they're originally spawned?
@Khalanil1: Go
My original reason was because if someone blocked, it would screw everything in the queue up. I have recently switched to a system that combines queuing the orders at the spawn, as well as using move regions to keep track of how far the units have traveled. I will detail this in the tutorial I post.
Using waits in triggers is safe because all variables are local. In Warcraft 3, it was not safe in GUI because loop variables / event response handles were global, and relied on the fact that only one trigger could execute at a time (but not true if it used a wait).
yea as vexal said, Waits are fine, providing you use Local variables ( that way it cant be overwritten) , Nothing is wrong with a wait.
The main issue is the Events i believe.
Either way ... if you change a couple things to the way I out lined it ... it will work 100% of the time... unless the unit is not actually dying.....
And then your players wont have to click a respawn button... which is what your post on the other site said you wanted to avoid....
also I personally avoid putting waits in any trigger that can be run multiple times while the one is currently running..... that trigger can be run lots and lots on top of itself...
I generally call a sub function to handle the heavy lifting.... doing this also helps me debug stuff.....
Eh anyways good luck with how ever you fix it
Waits can be necessary for things like trigger-controlled projectiles.