For efficiency place all points inside a point array of size 8. The first point goes in index 0 and the last point in index 7. You can then get a random point to create your unit at by getting a random integer in the range of 0 to 7 and using that as the index for the point array. This approach produces neater code (more maintainable) and runs faster.
Every time you run the code it will make a random unit at 1 of the 8 points. Due to the nature of randomness, consecutive runs might spawn units at the same point multiple times in a row. The number of units spawned in total will be equal to the number of times the code is run.
Be aware that for map testing purposes a fixed seed is often used. This means the same input will produce the same random results across multiple tests. This does not occur when played in the Arcade as then the random seed is not constant and will vary between sessions.
Also instead of a timer, I would just use a unit death event, and set it to the zerg that you want dead. If it is a preplaced zerg on the map, you can do it straight in the event itself.
StarCraft II unit events use special unit reference objects. These can be updated dynamically. after the event has been added to a trigger.
I recommend posting the full trigger. This can be done by selecting all elements in the GUI trigger window (ctrl+A) and then clicking on the root node (trigger name) and choosing to copy as text. It can then be passed inside code tags for a vaguely readable representation of the GUI). Alternatively you could upload the map to a cloud storage solution such as DropBox and then public link it in the post so people can see the trigger by looking at the map.
Use an array to map a player group to the dying units owner. If the dying unit has no associated player group then ignore it (not an AI player dying). Data tables can be used to resolve if the unit is an appropriate unit type efficiently with O(1) complexity.
Clean Empty Slots
Events
Game - Map initialization
Local Variables
Conditions
Actions
Player Group - Pick each player in (All players) and do (Actions)
Actions
General - If (Conditions) then do (Actions) else do (Actions)
If
Or
Conditions
(Status of player (Picked player)) == Unused
(Status of player (Picked player)) == Left The Game
Then
Unit Group - Pick each unit in (Any units in (Entire map) owned by player (Picked player) matching (No Value), with at most Any Amount) and do (Actions)
Actions
Unit - Remove (Picked unit) from the game
Else
Clean Dropper
Events
Player - Player Any Player leaves the game with Any
Local Variables
Conditions
Actions
Unit Group - Pick each unit in (Any units in (Entire map) owned by player (Triggering player) matching (No Value), with at most Any Amount) and do (Actions)
Actions
Unit - Remove (Picked unit) from the game
Check their status at map initialization. If they are not user controlled and playing then pick all units owned by them allowing everything and then remove the units. Run this test for all players in an integer loop.
In another trigger with a player leaves event you do the same actions for the triggering player.
Use a dummy unit that has the build ability and hook it to the UI. Similar to how the LotV campaign hooks all the Spear of Adun abilities to the panel at the top of the screen.
Triggering Player is the player who issued the order, at least for some events (maybe not the one you were trying to use). This was a big source of bugs in Undead Assault 3 as it assumed Triggering Player was the owning player so if you shared control and use another player's unit all manner of bugs occurred.
If there is only 1 (or a finite number) shops then maybe per player global variables might work. These are 16 sized arrays which index is the player slot number, providing unique storage for each player. I would have to see all the triggers to be able to comment further if this approach is appropriate or even needed.
So you want the oldest tumor from the caster to be destroyed when a new one is made? I would make the ability use a global Search Area effect that applies a buff stack when used. Using the history field of the Unit Compare Behavior Count validator (like the liberator) you could make the buff stacks only be applied to tumors spawned by the caster via a marker buff applied by the Create Unit effect or Build ability used. Then using a Switch effect under the search you could kill any tumour with 3 buff stacks if they belong to the caster.
This assumes the tumors cannot be killed as the result of combat damage or triggers and only by recasting the ability.
Zagara from Heroes of the Storm uses this mechanic on her Nydus Worm ultimate. Probious uses this mechanic on his Pylon trait. I wonder how Blizzard implemented it there...
Trigger approach would be on unit creation to add tumors to a unit group (might need to also purge dead ones from the group) and if the count of units in the group is greater than 3 then remove the first of group tumor (which is hopefully the oldest).
If one uses the spawn behaviour one might be able to achieve a similar result as that behaviour already has a spawn limit and automatically has a first made first dead result to spawning units past the limit.
What part of it is not working? Did you copy all of it? It probably uses models, actors, behaviours, effects and abilities as well as needing several assets.
You could also apply a custom lighting to the appropriate player with the HDR shader modified such that all brightness levels are black.
When you want visibility to go back to normal for that player, set the lighting back to what it was originally (usually defined by the tileset being used).
I also added that signature function to the bank to prevent tampering with. Seems to work alright for me.
It is nothing more than a well known SHA-1 checksum of a string built from the banks contents. Very easy to cheat and some people even made programs to sign any bank file.
Also nothing stops players deleting their bank file, resetting wins/losses to 0. For this reason you want the data in the banks to be nothing more than stats.
I think the only way to do this would be to rebuild the entire list every time an update is made. Keep track of the entire contents of the list in a string and then append the new messages to the beginning. Adding a message separator parser to the action may be required for correct reproduction.
Since the entire list is being rebuilt every call, this can be extremely resource intensive for long lists. In such a case you might want to buffer already wrapped list elements into a string array used as a first in last out list. Doing so keeps the scroll length manageable, removes the need to process a long string character by character and keeps execution time well bounded.
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
For efficiency place all points inside a point array of size 8. The first point goes in index 0 and the last point in index 7. You can then get a random point to create your unit at by getting a random integer in the range of 0 to 7 and using that as the index for the point array. This approach produces neater code (more maintainable) and runs faster.
Every time you run the code it will make a random unit at 1 of the 8 points. Due to the nature of randomness, consecutive runs might spawn units at the same point multiple times in a row. The number of units spawned in total will be equal to the number of times the code is run.
Be aware that for map testing purposes a fixed seed is often used. This means the same input will produce the same random results across multiple tests. This does not occur when played in the Arcade as then the random seed is not constant and will vary between sessions.
0
StarCraft II unit events use special unit reference objects. These can be updated dynamically. after the event has been added to a trigger.
I recommend posting the full trigger. This can be done by selecting all elements in the GUI trigger window (ctrl+A) and then clicking on the root node (trigger name) and choosing to copy as text. It can then be passed inside code tags for a vaguely readable representation of the GUI). Alternatively you could upload the map to a cloud storage solution such as DropBox and then public link it in the post so people can see the trigger by looking at the map.
0
Use an array to map a player group to the dying units owner. If the dying unit has no associated player group then ignore it (not an AI player dying). Data tables can be used to resolve if the unit is an appropriate unit type efficiently with O(1) complexity.
0
Here are some examples...
Clean Empty Slots Events Game - Map initialization Local Variables Conditions Actions Player Group - Pick each player in (All players) and do (Actions) Actions General - If (Conditions) then do (Actions) else do (Actions) If Or Conditions (Status of player (Picked player)) == Unused (Status of player (Picked player)) == Left The Game Then Unit Group - Pick each unit in (Any units in (Entire map) owned by player (Picked player) matching (No Value), with at most Any Amount) and do (Actions) Actions Unit - Remove (Picked unit) from the game ElseClean Dropper Events Player - Player Any Player leaves the game with Any Local Variables Conditions Actions Unit Group - Pick each unit in (Any units in (Entire map) owned by player (Triggering player) matching (No Value), with at most Any Amount) and do (Actions) Actions Unit - Remove (Picked unit) from the game0
Check their status at map initialization. If they are not user controlled and playing then pick all units owned by them allowing everything and then remove the units. Run this test for all players in an integer loop.
In another trigger with a player leaves event you do the same actions for the triggering player.
0
Modify the pylon warp in to do what you want. It places a building and is on the Spear of Adun control panel during the LotV campaign.
You will probably need to make a dedicated ability for it, like all those top panel abilities.
0
Use a dummy unit that has the build ability and hook it to the UI. Similar to how the LotV campaign hooks all the Spear of Adun abilities to the panel at the top of the screen.
0
Triggering Player is the player who issued the order, at least for some events (maybe not the one you were trying to use). This was a big source of bugs in Undead Assault 3 as it assumed Triggering Player was the owning player so if you shared control and use another player's unit all manner of bugs occurred.
If there is only 1 (or a finite number) shops then maybe per player global variables might work. These are 16 sized arrays which index is the player slot number, providing unique storage for each player. I would have to see all the triggers to be able to comment further if this approach is appropriate or even needed.
0
This assumes the tumors cannot be killed as the result of combat damage or triggers and only by recasting the ability.
Zagara from Heroes of the Storm uses this mechanic on her Nydus Worm ultimate. Probious uses this mechanic on his Pylon trait. I wonder how Blizzard implemented it there...
Trigger approach would be on unit creation to add tumors to a unit group (might need to also purge dead ones from the group) and if the count of units in the group is greater than 3 then remove the first of group tumor (which is hopefully the oldest).
If one uses the spawn behaviour one might be able to achieve a similar result as that behaviour already has a spawn limit and automatically has a first made first dead result to spawning units past the limit.
0
There is apparently a reprogrammable mat one can get which can simulate all amibos.
0
What part of it is not working? Did you copy all of it? It probably uses models, actors, behaviours, effects and abilities as well as needing several assets.
0
You could also apply a custom lighting to the appropriate player with the HDR shader modified such that all brightness levels are black.
When you want visibility to go back to normal for that player, set the lighting back to what it was originally (usually defined by the tileset being used).
0
It is nothing more than a well known SHA-1 checksum of a string built from the banks contents. Very easy to cheat and some people even made programs to sign any bank file.
Also nothing stops players deleting their bank file, resetting wins/losses to 0. For this reason you want the data in the banks to be nothing more than stats.
0
I think the only way to do this would be to rebuild the entire list every time an update is made. Keep track of the entire contents of the list in a string and then append the new messages to the beginning. Adding a message separator parser to the action may be required for correct reproduction.
Since the entire list is being rebuilt every call, this can be extremely resource intensive for long lists. In such a case you might want to buffer already wrapped list elements into a string array used as a first in last out list. Doing so keeps the scroll length manageable, removes the need to process a long string character by character and keeps execution time well bounded.
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%.