Sorry, yeah, I'm talking real time. WC3 had a serious issue with that (but I also think it suffered with gametime waits). Fortunately, timers with callback functions made precise timing possible (but that was only available in JASS).
In Warcraft 3, waits would get longer the more players there were in a game. Do waits work more correctly in SC2? That is, if I wanted a trigger to wait a second, would it wait for exactly a second (give or take a few milliseconds) or would it wait for way longer as it did in WC3?
I'd guess that it was done by creating an invisible (meaning no model) dummy unit for the tank at some angle for it to target with an attack order (and then stopping before it fired).
Or of course, it might also be doable by using a dummy ability to target said dummy unit (so it doesn't fire).
EDIT: Hmm. However... it still does its thing when it moves. Might want to give it the ability to attack while moving or something.
I'm not good with the data editor yet, but I was wondering if it's possible to have recursive effects (that also stop after a certain number in the chain). I'm fairly sure recursion is easy. The trouble is with terminating it at a certain count.
Wouldn't it just be better to use the CliffLevel validators? And I guess have each individual explosion effect (with 4 initial explosions, of course) chain into another explosion effect in one direction, but if a cliff is encountered, it shouldn't spawn the next explosion in that chain... terminating the chain in that direction.
Of course, you'll also want to validate the initial explosion.
I can see how you are confused. I'll let the real help come from the more experienced ones, but I can tell you why your second image's trigger is not working.
You have it set up so that if those units are all in those spots all at one time, then they die. You cannot have more than one event and expect the trigger to just run on one. You could have the trigger recognize the different events, probably with an OR function.
Pretty sure you're talking about conditions, not events. If you have a bunch of events in a trigger, the trigger will fire when one of these events occur. Think about it, how does it make sense to have it only fire when multiple events occur simultaneously? Events are instantaneous; they do not persist beyond a frame.
I believe the way events work in SC2 (and WC3) is that when you register an event to a trigger, the game registers an event hook so that when something happens that there is an event for, it knows to fire any triggers registered with this event. I don't know if this is true, but I generally imagine this to be how it works. I would do it like this if I had made WC3/SC2.
Or you could set a boolean for when you start spawning these units, and you simply use the trigger you would to check if there are none alive, but check if the boolean is true.
0
You sir, win the contest.
0
I just don't understand why Bnet 2.0 couldn't do what Garena or pickup listchecker did for classic Bnet.
0
I'm pretty glad the mods here don't seem so draconian. <3 you guys.
0
i herd u liek reperz
Seriously, what is this I don't even
0
Can't you just pass the length of the array into the function as a parameter?
0
Bump is correct, although the OP wasn't asking for a stack structure. You can use a variable to track the operating size of the array.
0
Are you comparing the points between the source and the target, or the caster and the target? These are two different things, I believe.
0
Sorry, yeah, I'm talking real time. WC3 had a serious issue with that (but I also think it suffered with gametime waits). Fortunately, timers with callback functions made precise timing possible (but that was only available in JASS).
0
In Warcraft 3, waits would get longer the more players there were in a game. Do waits work more correctly in SC2? That is, if I wanted a trigger to wait a second, would it wait for exactly a second (give or take a few milliseconds) or would it wait for way longer as it did in WC3?
0
I'd guess that it was done by creating an invisible (meaning no model) dummy unit for the tank at some angle for it to target with an attack order (and then stopping before it fired).
Or of course, it might also be doable by using a dummy ability to target said dummy unit (so it doesn't fire).
EDIT: Hmm. However... it still does its thing when it moves. Might want to give it the ability to attack while moving or something.
0
Ah! I think I see something of value here. Evidently, there's a periodic offset field you might be able to make some use of here...
Yes, use this along with Periodic Validator (to check the cliff level). I have a hunch this should help.
EDIT: So the trick here is to think iteratively, not recursively, I guess.
0
I'm not good with the data editor yet, but I was wondering if it's possible to have recursive effects (that also stop after a certain number in the chain). I'm fairly sure recursion is easy. The trouble is with terminating it at a certain count.
0
Wouldn't it just be better to use the CliffLevel validators? And I guess have each individual explosion effect (with 4 initial explosions, of course) chain into another explosion effect in one direction, but if a cliff is encountered, it shouldn't spawn the next explosion in that chain... terminating the chain in that direction.
Of course, you'll also want to validate the initial explosion.
0
Pretty sure you're talking about conditions, not events. If you have a bunch of events in a trigger, the trigger will fire when one of these events occur. Think about it, how does it make sense to have it only fire when multiple events occur simultaneously? Events are instantaneous; they do not persist beyond a frame.
I believe the way events work in SC2 (and WC3) is that when you register an event to a trigger, the game registers an event hook so that when something happens that there is an event for, it knows to fire any triggers registered with this event. I don't know if this is true, but I generally imagine this to be how it works. I would do it like this if I had made WC3/SC2.
0
Or you could set a boolean for when you start spawning these units, and you simply use the trigger you would to check if there are none alive, but check if the boolean is true.
E.g.:
Actually, you might not even need the boolean. Just turn on the trigger when it's time to spawn.