I would doubt they'd keep getting the buff, but since this is a data thing, I'm not entirely sure. I know triggers for instance, you can make things necessary and exclude them altogether. For example the "pick each unit in unit group" combined with "units in region matching condition" by default excludes dead units. Is there not something like that when creating your buff?
This will show observers what they said, but I'm not sure how to differentiate between All chat and allied chat. So observers will see the All chat message twice if you use this.
Just change the global variable from active players to the actual observers.
Edit: Oh, and you should probably add a condition so that it doesn't include the observer players' messages as well.
Ah, so any unit being created somewhere counts as it entering that area? I wasn't aware of that, pretty cool. I imagine something like that trigger might also want a wait action til the building is no longer under construction.
Huh, that's really weird. There's actions to add and remove units from control groups, but I don't see any way of finding out if a unit is in a control group, or a function to reference that control group as a whole. Pretty odd.
I believe onetwoSC did a tutorial about critter respawn, or something similar. The neat thing about his, was he stored the x and y positions of the units into a custom value of the unit. In this way he was able to have the units always respawn at the same point. It looked something like this.
Map initialization
Pick each unit for player 15
Store x of point (position of picked unit) into custom value 5 (or w/e number you want) of picked unit
Store y of point.... custom value 6...
Second trigger
Unit dies
Condition: unit is on player 15 team
wait X seconds
Create unit at point (custom value 5 of triggering unit, custom value 6 of triggering unit), Or store the the point in a local variable first if the wait is screwing it up
Store the custom values again like first trigger into the newly created unit.
Like Funky, I'm not sure what your condition is for. I'm not sure it's even needed. Also, you probably only need the remove unit action under the pick each loop.
I typically offset my dialog items from the edges of the dialog and other dialog items by 25. With buttons i tend to go with the default 200, 50, unless I have more text or some kind of emphasis to put on the button. Even so, I'll frequently make changes and use the test map button a lot to see how it looks. One thing that can make changes easy is if you set the basic dimensions you want in the local variables, then base the rest of the stuff on arithmetic using those variables.
For example I might do something like
Local variables
Button Width = 200
Then for all the button widths I'll set it equal to that variable. For the dialog width, I'll set it to button width + 50 (since I like to have 25 on both sides of the button). That way I can easily make a change to all the buttons' and the dialog's width by just changing that local variable.
How about just putting the (starting) speed into a real variable yourself. Then whenever you modify the catalog speed, you could also modify the real variable. Hopefully you don't have too many unit types you'll be modifying though...
0
Well, you would have to revive them immediately as they die and then hide them through actions like hide unit. Then after the 60 seconds, unhide them.
0
I would doubt they'd keep getting the buff, but since this is a data thing, I'm not entirely sure. I know triggers for instance, you can make things necessary and exclude them altogether. For example the "pick each unit in unit group" combined with "units in region matching condition" by default excludes dead units. Is there not something like that when creating your buff?
0
This will show observers what they said, but I'm not sure how to differentiate between All chat and allied chat. So observers will see the All chat message twice if you use this.
Just change the global variable from active players to the actual observers.
Edit: Oh, and you should probably add a condition so that it doesn't include the observer players' messages as well.
0
If this is possible, I imagine you would need to edit the data of each unit type, and give them longer death times.
0
@BasharTeg: Go
Ah, so any unit being created somewhere counts as it entering that area? I wasn't aware of that, pretty cool. I imagine something like that trigger might also want a wait action til the building is no longer under construction.
@Diego6D: Go
Create unit action.
0
There's a mouse click event, and a issue order action. You would specify the location of the order as the mouse position x and y.
0
Huh, that's really weird. There's actions to add and remove units from control groups, but I don't see any way of finding out if a unit is in a control group, or a function to reference that control group as a whole. Pretty odd.
0
I imagine using a periodic event instead of a while loop would probably fix it.
0
I suppose you would have to make some kind of path blockers and give the enemies a large pathing footprint so that they cannot enter it.
0
You can use the "unit uses ability" as the event. To get rid of the ability with triggers you can use the action "allow/disallow ability for player".
0
@Reul123: Go
Unless he has a good twin! Sounds like a conspiracy...
@Diego6D: Go
I believe onetwoSC did a tutorial about critter respawn, or something similar. The neat thing about his, was he stored the x and y positions of the units into a custom value of the unit. In this way he was able to have the units always respawn at the same point. It looked something like this.
Map initialization
Pick each unit for player 15
Store x of point (position of picked unit) into custom value 5 (or w/e number you want) of picked unit
Store y of point.... custom value 6...
Second trigger
Unit dies
Condition: unit is on player 15 team
wait X seconds
Create unit at point (custom value 5 of triggering unit, custom value 6 of triggering unit), Or store the the point in a local variable first if the wait is screwing it up
Store the custom values again like first trigger into the newly created unit.
0
Like Funky, I'm not sure what your condition is for. I'm not sure it's even needed. Also, you probably only need the remove unit action under the pick each loop.
0
I typically offset my dialog items from the edges of the dialog and other dialog items by 25. With buttons i tend to go with the default 200, 50, unless I have more text or some kind of emphasis to put on the button. Even so, I'll frequently make changes and use the test map button a lot to see how it looks. One thing that can make changes easy is if you set the basic dimensions you want in the local variables, then base the rest of the stuff on arithmetic using those variables.
For example I might do something like
Local variables
Button Width = 200
Then for all the button widths I'll set it equal to that variable. For the dialog width, I'll set it to button width + 50 (since I like to have 25 on both sides of the button). That way I can easily make a change to all the buttons' and the dialog's width by just changing that local variable.
0
How about just putting the (starting) speed into a real variable yourself. Then whenever you modify the catalog speed, you could also modify the real variable. Hopefully you don't have too many unit types you'll be modifying though...
0
Not sure about the first part, sounds like something for the data editor.
As for the second part, yes you could replicate one instantaneously, or you could just revive it instantly too. Something like this should work