That is basically how you make the AI, by polling things periodically and making it do something if the conditions are met.
For mechanics such as ganking you want to some global state that sets possible gank targets. The AI then react to this with another test in the polling loop. Targeting low health heroes should be automatically part of the standard AI.
I would advise looking into how Blizzard has made the Skeletal Mage ultimate for Xul in Heroes of the Storm. The most recent version of it summons units in an orientation that are rotated by dragging your mouse cursor before releasing. Since HotS is based on the same engine as SC2 it is possible the same mechanics can be used, assuming there have not been too many major diversions between the game engines.
If using such mechanics is possible, one would create a unit at the initial target and then rotate it to the drag vector, using triggers if required.
There are 2 types of drop pod. You have not made it clear which you are referring to.
For trained unit drops, eg Raynor barracks dropping at rally point, the drop pod works by instantly hiding the trained unit, doing the drop pod art, and then unhiding the trained unit after the impact time.
For units created after the drop pod lands, eg Zagara drop, the drop pod art is created and then the unit is created after the impact time.
For trained drops you can move the hidden unit anywhere you want at any time after training. It should even unhide automatically after the drop art finished. You could also force it to unhide immediately by removing the buff used.
For drops that create units then you cannot move the units until after the drop has completed. It can be done the instant the drop finished but not before because no units exist yet that can be moved. One could alter such drops to allow movement by using a dummy unit (the drop pod?) and always spawning the units at the unit location rather than the original target location. One can then move this dummy unit around with triggers and the drops will be move appropriately.
To create multiple unit types from a drop that creates units you use a set effect to run multiple create unit effects at once.
You should be able to move them immediately as they are created but hidden until the drop pod lands. They might only become visible at their new location after the pod lands however.
In data add to the upgrade modification list a modifier to multiply or add damage to the damage effects the unit uses. Multiplying by 1.1 will increase relative damage by 10%, where as adding a constant can increase damage 10% additively.
If there is only 1 upgrade level you can give the unit a buff class behaviour which increases damage by 10% and has a requirement of the upgrade. Once the upgrade is researched the behaviour turns on and increases damage by 10%.
With triggers one can use the catalog actions to achieve something similar to upgrading the unit's damage effect directly with the upgrade. One could also add stacks of a behaviour to the unit, each stack increasing damage by 10%.
Oh ok. So I create a Variable of the type "- record". If I set the Variable to Array of 16, can I then have 16 different instances of the Record? So that Record[1].Integer and Record[2].Integer are different values, or will I have to do it like Record.Integer[1] and Record.Integer[2]?
Record[1].Integer is the Integer member belonging to index 1 of the Record struct array.
Record.Integer[1] is the index 1 of the Integer array member belonging to Record struct.
"Records" in GUI translate to structs in galaxy. They define a type so cannot be used for storage directly. One has to create a variable of the type before it can be used for storage.
In real programing structs/classes have memory/access performance benefits over parallel arrays. I doubt these matter so much with galaxy.
Is there currently any good reason to not use this?
I do not know the exact behaviour of the native/function. As such I cannot suggest it to anyone as I might suggest its use incorrectly.
Specifically "active players" meaning is ambiguous to some extent. Computers could technically be active if they have not been defeated/won and were defined as slot controllers before the start. Like wise players that were active at the start of the game might have been defeated/won/left so might be considered inactive. It obviously has a well defined behaviour with what it returns just I do not know what that is and cannot be bothered to extensively test it and will likely forget it in years to as well.
As such I suggested a for all player loop with filters. These filters I can explicitly define and do know what they do so I can be sure the trigger would work. Performance wise it might not be the most efficient solution or the most compact solution code wise, but none of that matters as it will make no difference to gameplay at all.
Something like the following should do the trick...
Active Player Count Test
Events
Local Variables
active player count = 0 <Integer>
p = 0 <Integer>
Conditions
Actions
Player Group - For each player p in (All players) do (Actions)
Actions
General - If (Conditions) then do (Actions) else do (Actions)
If
(Controller of player p) == User
(Status of player p) == Playing
Then
Variable - Modify active player count: + 1
Else
General - If (Conditions) then do (Actions) else do (Actions)
If
active player count > 2
Then
------- "kill trigger" stuff goes here
Else
The logic to find active player count could be put into any trigger you want or even made into an action for convenience.
Is there some way to get a trigger that activates the 'kill trigger' only when a 3/4 human controlled players are active?
Yes, you do exactly what you wrote in trigger form...
Count number of active human controlled players and if that number is greater than 2 then run "kill trigger" otherwise do nothing. Counting the number of active human controlled players is as simple as counting the number of players that are human controlled and still playing by looping through all players and incrementing a counter if a player meets that condition.
0.963144963144963
You could try hooking up custom UI elements to the unit information panel to show these values.
0.967625899280576
That is basically how you make the AI, by polling things periodically and making it do something if the conditions are met.
For mechanics such as ganking you want to some global state that sets possible gank targets. The AI then react to this with another test in the polling loop. Targeting low health heroes should be automatically part of the standard AI.
0.967391304347826
I would advise looking into how Blizzard has made the Skeletal Mage ultimate for Xul in Heroes of the Storm. The most recent version of it summons units in an orientation that are rotated by dragging your mouse cursor before releasing. Since HotS is based on the same engine as SC2 it is possible the same mechanics can be used, assuming there have not been too many major diversions between the game engines.
If using such mechanics is possible, one would create a unit at the initial target and then rotate it to the drag vector, using triggers if required.
0.966292134831461
There are 2 types of drop pod. You have not made it clear which you are referring to.
For trained unit drops, eg Raynor barracks dropping at rally point, the drop pod works by instantly hiding the trained unit, doing the drop pod art, and then unhiding the trained unit after the impact time.
For units created after the drop pod lands, eg Zagara drop, the drop pod art is created and then the unit is created after the impact time.
For trained drops you can move the hidden unit anywhere you want at any time after training. It should even unhide automatically after the drop art finished. You could also force it to unhide immediately by removing the buff used.
For drops that create units then you cannot move the units until after the drop has completed. It can be done the instant the drop finished but not before because no units exist yet that can be moved. One could alter such drops to allow movement by using a dummy unit (the drop pod?) and always spawning the units at the unit location rather than the original target location. One can then move this dummy unit around with triggers and the drops will be move appropriately.
To create multiple unit types from a drop that creates units you use a set effect to run multiple create unit effects at once.
0.966165413533835
You should be able to move them immediately as they are created but hidden until the drop pod lands. They might only become visible at their new location after the pod lands however.
0.96128170894526
In data add to the upgrade modification list a modifier to multiply or add damage to the damage effects the unit uses. Multiplying by 1.1 will increase relative damage by 10%, where as adding a constant can increase damage 10% additively.
If there is only 1 upgrade level you can give the unit a buff class behaviour which increases damage by 10% and has a requirement of the upgrade. Once the upgrade is researched the behaviour turns on and increases damage by 10%.
With triggers one can use the catalog actions to achieve something similar to upgrading the unit's damage effect directly with the upgrade. One could also add stacks of a behaviour to the unit, each stack increasing damage by 10%.
0.981132075471698
1
I do not know the exact behaviour of the native/function. As such I cannot suggest it to anyone as I might suggest its use incorrectly.
Specifically "active players" meaning is ambiguous to some extent. Computers could technically be active if they have not been defeated/won and were defined as slot controllers before the start. Like wise players that were active at the start of the game might have been defeated/won/left so might be considered inactive. It obviously has a well defined behaviour with what it returns just I do not know what that is and cannot be bothered to extensively test it and will likely forget it in years to as well.
As such I suggested a for all player loop with filters. These filters I can explicitly define and do know what they do so I can be sure the trigger would work. Performance wise it might not be the most efficient solution or the most compact solution code wise, but none of that matters as it will make no difference to gameplay at all.
1
Something like the following should do the trick...
Active Player Count Test Events Local Variables active player count = 0 <Integer> p = 0 <Integer> Conditions Actions Player Group - For each player p in (All players) do (Actions) Actions General - If (Conditions) then do (Actions) else do (Actions) If (Controller of player p) == User (Status of player p) == Playing Then Variable - Modify active player count: + 1 Else General - If (Conditions) then do (Actions) else do (Actions) If active player count > 2 Then ------- "kill trigger" stuff goes here ElseThe logic to find active player count could be put into any trigger you want or even made into an action for convenience.
1
Yes, you do exactly what you wrote in trigger form...
Count number of active human controlled players and if that number is greater than 2 then run "kill trigger" otherwise do nothing. Counting the number of active human controlled players is as simple as counting the number of players that are human controlled and still playing by looping through all players and incrementing a counter if a player meets that condition.