Nearest WP
Options: Function
Return Type: Point
Parameters
from = No Point <Point>
Grammar Text: Nearest WP(from)
Hint Text: (None)
Custom Script Code
Local Variables
i = 0 <Integer>
nearest = WayPoints[0] <Point>
amount = (Distance between from and WayPoints[0]) <Real>
temp = 0.0 <Real>
Actions
General - For each integer i from 1 to 9 with increment 1, do (Actions)
Actions
Variable - Set temp = (Distance between from and WayPoints[i])
General - If (Conditions) then do (Actions) else do (Actions)
If
temp < amount
Then
Variable - Set amount = temp
Variable - Set nearest = WayPoints[i]
Else
General - Return nearest
Sounds like a simple unit group per player would suffice. When any unit dies you check the group for the owner (use his player as the index in the group array) and if the number of living units in the group is 0 (everything dead) then respawn X civilians (where X is stored in an integer array representing how many civilian milestones he reached).
If you mean that the civilians respawn once all the units it created die (not when all units the player owns are dead) then it is more tricky. In that situation I would recommend using threads for holding the group of spawned units in a local group and then periodicly polling it (every 5-10 seconds) to check if all units in it are dead or not. This would handle the dynamic memory nature of the problem although it does add a upper bound to the number of civilians that can exist (something you should have anyway to prevent poor performance).
No, there is no trigger within the triggers window that can change the range of a search area effect, or change a search area effect directly.
The catalog natives allow you to directly change the area of search effects with triggers. The following line of GUI changes the area of the High Templar Psionic Storm to 50.
Catalog - Set value of Effects PsiStormSearch AreaArray[0].Radius for player (Triggering player) to "50"
It really is that simple. The catalog natives allow you read access to every field in the data editor but only "upgradeable" fields (fields that can be modified with upgrades) support writing to with the set native.
It should be noted that the field parameter does not default to the entry type of the entry field. As such you manually need to select Search for it so that the right fields are choose-able. Alternatively you can write the field path as a custom script string using XML view in the data editor to find the field structure.
Such heavy randomness in a PvP game is not recommended. Even if most of the choices are balanced people will always blame their loss on the "RNG" even if it is not true.
The best you can do is have randomness as an element that affects everyone equally. For example ability powerups that randomly spawn but at fixed locations balanced for reach by both teams. Making the PvP aspect based on randomness will probably result in a low popularity map as people will not find it competitive enough.
What exactly are you trying to do? If you plan to have a bounded number of units in the unit group with particular places then maybe consider a 2D unit array instead. Groups are meant to be used as sets of units where internal placement inside the group is unimportant so what you are trying to do is sort of outside their use case. By elaborating what you intend to do and why there might be alternative solutions that are easier/more efficient that you are unaware of (triggering can be complex stuff at times).
It may be possible to order units inside a group by clearing it and adding them in the correct order. More efficient would be to swap the group so you pull units from one in the correct order and put them straight into a new unit group which you eventually use to replace the first. That is if units are given a place inside the group based on order of addition and not some internal data structure mechanic based on some internal identifier. For example if a group was a AVL tree of units then the ordering might be based on internal numbers outside your control.
However, with a Charge Count (Use) of 0, there are some inexplicable issues. Even though I have a Charge Count (Start) of 0, the ability starts with the max number of charges, 5. Attempting to remove charges via trigger does nothing. Setting any value for Charge Time Start or Charge Time Use does nothing as well.
I ran into similar issues with ability charges and triggers. Some times the natives work and correctly modify charges, while other times they appear to be ignored entirely. I did notice that if the unit is subject to ownership change the ability charge number appears to be reset to maximum automatically and cannot be modified instantaneously (at time of transfer). You could try using 1 frame waits and attempt to set the charges multiple times until they are set correctly.
It is important you get your mechanics working first. Having beautifully sculptured terrain is pointless if you find out what you wanted to do is not possible.
Do not simply try to re-create a map, improve upon it or give it a "twist" or something that makes it stand out. After all why should people play your alpha/beta version map when there exists already a highly polished one.
In the case of a custom hero defence map you would want to try and create a hero with 1-2 working skills with 1-2 options or something of the sort to make sure your core mechanics are working. Then it is a lot of grunt working adding new content.
Content creation itself is difficult. If I remember that map at least 50% of choices were unusable since there was always better. That is an inherit problem with that sort of map but you would want to minimize it maybe by locking out incompatible choices or streamlining to some extent. Try and make each ability different in the situation it is used so that everyone does not do the best simply by spamming out damage and debuffs etc.
A big problem you will encounter is the standard SC2 armor mechanics. If you have enough armor you could end up taking only 0.5 damage from attacks while if you give the enemies too much damage even the tanks will fall fast. Consider migrating to a WC3 style armor system (% more equivalent HP per point) or one which scales better.
Avoid statistic hyper inflation. Sure you want your final waves to be tough, but that does not mean they need 1000 times more stats than the first wave.
Design your save mechanics right first time. It is not something you want to re-design post release as it will really annoy a lot of players. The author of the map you mention failed to do this so repeatedly wiped everyone to the point at least 70% of people quit.
Be realistic about content acquisition. Difficulty unlocks are ok if the difficulty is reasonable to win (no "requires mega super impossible god mode to be beaten"). "Grinding" unlocks should also be reasonable to acquire (20-40 hours max for everything) with reasonable spacing (avoid unlocking everything at start then expect the person to play an extra 20 hours to unlock the last thing). Do keep in mind that your map is one of many in SC2 so it is not reasonable expecting them to play it for hundreds of hours such as a stand alone game like Diablo III does.
It should be noted that Special Forces 5 is a "unit spam" map (for anyone who has not played it) where there can be several hundred units in tight proximity at times. As such any ability needs to be reasonably efficient to avoid excessive resource consumption. This also means that excessive visual effects must be avoided as applying a graphic intensive asset to 50 units on screen at once will cause the game to perform poorly.
I also remember that you have an event "unit dies", but in the actions you have "spawn X for (triggering player). correct me if i'm wrong, but that should read "spawn X for (Owner of triggering unit)"
If you read the help text on the event it says that (triggering player) in this case is the same as owner of dying unit. To avoid excessive native calls it should probably be cached in a local variable.
However in the case of any ability cast event it is different since it returns the ordering player (who could not be the owner in the case of shared control) but that is only for such events.
hey thanks for checking it out. as far as the unit attached to region playable map goes, it is not that same as any unit. "any unit " does not work for me in this case. the region "PLAYABLE MAP" is the region of the map that is the battlefield outside of the civilian area. i dont want it to trigger when a civilian dies, only when units on the battlefield dies. it works this way.
No it does not work that way. You are misunderstanding what is happening from the Galaxy virtual machine point of view.
At map initialization it gets the unit you attached the region to (null since the region is not attached to any unit) and then makes a unit reference to null. This is the same as saying any unit.
It is clearly stated in the native list what will happen.
// Unit events// - Use a null unit for "any unit" events// - When a unitref within an event refers to a variable with a null value, by default this is also// treated as "any unit". However, if UnitEventSetNullVariableInvalid is set to true, then null// variable refs within events are treated as "no unit" instead, meaning that the event will never// fire.
Since you are making a null unit ref it is equivalent to any unit. Galaxy is not declarative so it will not dynamically re-evaluate functions automatically just because it sounds right (although that would be cool but probably too performance intensive). Once you make a unit ref using the "UnitRefFromUnit" function (which is how GUI does it), it is impossible to change the unit. The only time references will change is if they are made from "UnitRefFromVariable" (GUI does this if you give it a global unit variable as an argument) in which case it will reference what ever unit is in the variable.
What you want to do is add a condition to the triggers check if the dying unit's point was within the PLAYABLE MAP region (equal to true, its a boolean test). That performs the logic you want as any unit dying outside the region will fail the condition so the actions will not run.
also, everyone is hitting 0 supply... i have checked with the players and checked the replays. it seems i got everything right except for the respawn. i dont have a problem with team set up and lobby anymore. its respawning for me and no1 else, it might have to do with something in the "NEXUS SET UP" trigger
You need to find out if the triggers are actually running. I recall Galaxy having some kind of limit to the number of event sockets for some event types. It could be that you attach so many "any unit dies" events that it runs out of sockets so not all triggers have an event. I would strongly recommend trying to merge the triggers together into 1 with more selection logic as that would be more efficient and avoid this problem (if it is the cause).
You update the alliances for both teams every time someone is added to team 2. This means if the last player was added to team 1 he will not get allied properly by that trigger. What you want to do instead is place everyone into teams inside the loop and then outside the loop you ally them. This way you can ally them all by running 2 lines of script at the end instead of currently where it could possibly bug and will re-ally everyone every time someone is added to team 2 (which is a waste of processor time as no everyone may be in the teams yet).
To get the lines outside the loop drag them to the gap below the root node of the loop (the actual loop statement) but before it indents for the looping code. They will then appear on the same line as the loop root but after the actual loop block.
1.Shock Grenade – A grenade just like Tychus’ that explodes, stunning all surviving enemies
So they are stunned permanently? By surviving you mean it has a percentage chance to kill stuff instantly?
You need to be much more clear about all the abilities exact effects or you might not get what you want.
this script dont work if i make a timer for wave on condition. like:
TriggerAddEventTimePeriodic(10,c_timeGame)
That is because that is an "event" not a "condition"?
This is the first time I am reading anything about periodic events. What job must be done periodically?
If you want to periodically spawn all units placed then use some kind of array system to track them. Use a 2 dimensional int array where each column represents the unit type spawned and each row the spawn point with the value being the number to spawn. You could use a boolean array in parallel to rows (via struct or a separate array) to keep track of which spawn points have units to spawn so that you do not bother checking the columns needlessly. The mapping of column to unit type could be done with a unit type array.
Many of your units have 2 unit actors which is now allowed. It even tells you this error when you start the editor. This has nothing to do with the problem mentioned. It is caused by you having made exact copies of unit actors so that 2 unit actors attempt to be made for the same unit. To fix I would recommend deleting the actor copies and modifying the original. You might have meant for them to be created for a copy of the marine unit in which case you need to change the event subject to your copy and not the original.
Your events make no sense. : "Unit - (Unit attached to Region playable map) dies" : The region "playable map" is not attached to any unit? As such it is equivalently saying "any" unit dies. I think you are misunderstanding what that function does. Or maybe I am missing something about it? I mean your the second person today I have seen use it like this which seems illogical and should act the same as "any unit" in this case.
The logic in "NEXUS SET UP" appears illogical. You might want to update alliances outside the loop and not inside. This way all alliance settings are done in a single call at the end after the teams are built.
As for the repawning... You sure everyone is hitting 0 supply? Are all the triggers firing?
Assign all units spawned at each point to a unit group (add them to the group). Before spawning new units, check if there is space in the unit group (number of living units in unit group < X where X is the number of units you want). This why no more than X can exist at a time.
You may need to flush dead units from the groups from time to time, I am uncertain if SC2 does this automatically and if not it could possibly be a leak of sorts.
You could also assign an integer to each spawn point to buffer "over spawns" so that you can spawn them at a later time if you wanted but that could change the dynamics of your game.
Ultimately making it some form of data driven system would be great. That way all spawns could be run from the same triggers and new spawns or spawn removal would be as easy as setting some variables. One approach for such a system would be an array of structs (forget what they are called in GUI) which each index represents a spawner. You set all indicies up at map initialization and then periodically check through each one spawning when appropriate. To spawn all you need is a location (where the spawn is), a group (the number of currently alive spawns) and possibly an integer (how many ticks until spawn) and another integer (how many ticks until respawn, the period). For over spawn support you would need an integer (how many spawns could not be spawned but wanted to).
0
Simple minimum search.
Nearest WP Options: Function Return Type: Point Parameters from = No Point <Point> Grammar Text: Nearest WP(from) Hint Text: (None) Custom Script Code Local Variables i = 0 <Integer> nearest = WayPoints[0] <Point> amount = (Distance between from and WayPoints[0]) <Real> temp = 0.0 <Real> Actions General - For each integer i from 1 to 9 with increment 1, do (Actions) Actions Variable - Set temp = (Distance between from and WayPoints[i]) General - If (Conditions) then do (Actions) else do (Actions) If temp < amount Then Variable - Set amount = temp Variable - Set nearest = WayPoints[i] Else General - Return nearest0
Sounds like a simple unit group per player would suffice. When any unit dies you check the group for the owner (use his player as the index in the group array) and if the number of living units in the group is 0 (everything dead) then respawn X civilians (where X is stored in an integer array representing how many civilian milestones he reached).
If you mean that the civilians respawn once all the units it created die (not when all units the player owns are dead) then it is more tricky. In that situation I would recommend using threads for holding the group of spawned units in a local group and then periodicly polling it (every 5-10 seconds) to check if all units in it are dead or not. This would handle the dynamic memory nature of the problem although it does add a upper bound to the number of civilians that can exist (something you should have anyway to prevent poor performance).
0
The catalog natives allow you to directly change the area of search effects with triggers. The following line of GUI changes the area of the High Templar Psionic Storm to 50.
Catalog - Set value of Effects PsiStormSearch AreaArray[0].Radius for player (Triggering player) to "50"
It really is that simple. The catalog natives allow you read access to every field in the data editor but only "upgradeable" fields (fields that can be modified with upgrades) support writing to with the set native.
It should be noted that the field parameter does not default to the entry type of the entry field. As such you manually need to select Search for it so that the right fields are choose-able. Alternatively you can write the field path as a custom script string using XML view in the data editor to find the field structure.
0
Write you what? You have not asked for anything else other than the initial fix which appeared to be working.
0
Such heavy randomness in a PvP game is not recommended. Even if most of the choices are balanced people will always blame their loss on the "RNG" even if it is not true.
The best you can do is have randomness as an element that affects everyone equally. For example ability powerups that randomly spawn but at fixed locations balanced for reach by both teams. Making the PvP aspect based on randomness will probably result in a low popularity map as people will not find it competitive enough.
0
What exactly are you trying to do? If you plan to have a bounded number of units in the unit group with particular places then maybe consider a 2D unit array instead. Groups are meant to be used as sets of units where internal placement inside the group is unimportant so what you are trying to do is sort of outside their use case. By elaborating what you intend to do and why there might be alternative solutions that are easier/more efficient that you are unaware of (triggering can be complex stuff at times).
It may be possible to order units inside a group by clearing it and adding them in the correct order. More efficient would be to swap the group so you pull units from one in the correct order and put them straight into a new unit group which you eventually use to replace the first. That is if units are given a place inside the group based on order of addition and not some internal data structure mechanic based on some internal identifier. For example if a group was a AVL tree of units then the ordering might be based on internal numbers outside your control.
0
I ran into similar issues with ability charges and triggers. Some times the natives work and correctly modify charges, while other times they appear to be ignored entirely. I did notice that if the unit is subject to ownership change the ability charge number appears to be reset to maximum automatically and cannot be modified instantaneously (at time of transfer). You could try using 1 frame waits and attempt to set the charges multiple times until they are set correctly.
0
It is important you get your mechanics working first. Having beautifully sculptured terrain is pointless if you find out what you wanted to do is not possible.
Do not simply try to re-create a map, improve upon it or give it a "twist" or something that makes it stand out. After all why should people play your alpha/beta version map when there exists already a highly polished one.
In the case of a custom hero defence map you would want to try and create a hero with 1-2 working skills with 1-2 options or something of the sort to make sure your core mechanics are working. Then it is a lot of grunt working adding new content.
Content creation itself is difficult. If I remember that map at least 50% of choices were unusable since there was always better. That is an inherit problem with that sort of map but you would want to minimize it maybe by locking out incompatible choices or streamlining to some extent. Try and make each ability different in the situation it is used so that everyone does not do the best simply by spamming out damage and debuffs etc.
A big problem you will encounter is the standard SC2 armor mechanics. If you have enough armor you could end up taking only 0.5 damage from attacks while if you give the enemies too much damage even the tanks will fall fast. Consider migrating to a WC3 style armor system (% more equivalent HP per point) or one which scales better.
Avoid statistic hyper inflation. Sure you want your final waves to be tough, but that does not mean they need 1000 times more stats than the first wave.
Design your save mechanics right first time. It is not something you want to re-design post release as it will really annoy a lot of players. The author of the map you mention failed to do this so repeatedly wiped everyone to the point at least 70% of people quit.
Be realistic about content acquisition. Difficulty unlocks are ok if the difficulty is reasonable to win (no "requires mega super impossible god mode to be beaten"). "Grinding" unlocks should also be reasonable to acquire (20-40 hours max for everything) with reasonable spacing (avoid unlocking everything at start then expect the person to play an extra 20 hours to unlock the last thing). Do keep in mind that your map is one of many in SC2 so it is not reasonable expecting them to play it for hundreds of hours such as a stand alone game like Diablo III does.
0
It should be noted that Special Forces 5 is a "unit spam" map (for anyone who has not played it) where there can be several hundred units in tight proximity at times. As such any ability needs to be reasonably efficient to avoid excessive resource consumption. This also means that excessive visual effects must be avoided as applying a graphic intensive asset to 50 units on screen at once will cause the game to perform poorly.
0
If you read the help text on the event it says that (triggering player) in this case is the same as owner of dying unit. To avoid excessive native calls it should probably be cached in a local variable.
However in the case of any ability cast event it is different since it returns the ordering player (who could not be the owner in the case of shared control) but that is only for such events.
0
No it does not work that way. You are misunderstanding what is happening from the Galaxy virtual machine point of view.
At map initialization it gets the unit you attached the region to (null since the region is not attached to any unit) and then makes a unit reference to null. This is the same as saying any unit.
It is clearly stated in the native list what will happen.
Since you are making a null unit ref it is equivalent to any unit. Galaxy is not declarative so it will not dynamically re-evaluate functions automatically just because it sounds right (although that would be cool but probably too performance intensive). Once you make a unit ref using the "UnitRefFromUnit" function (which is how GUI does it), it is impossible to change the unit. The only time references will change is if they are made from "UnitRefFromVariable" (GUI does this if you give it a global unit variable as an argument) in which case it will reference what ever unit is in the variable.
What you want to do is add a condition to the triggers check if the dying unit's point was within the PLAYABLE MAP region (equal to true, its a boolean test). That performs the logic you want as any unit dying outside the region will fail the condition so the actions will not run.
You need to find out if the triggers are actually running. I recall Galaxy having some kind of limit to the number of event sockets for some event types. It could be that you attach so many "any unit dies" events that it runs out of sockets so not all triggers have an event. I would strongly recommend trying to merge the triggers together into 1 with more selection logic as that would be more efficient and avoid this problem (if it is the cause).
You update the alliances for both teams every time someone is added to team 2. This means if the last player was added to team 1 he will not get allied properly by that trigger. What you want to do instead is place everyone into teams inside the loop and then outside the loop you ally them. This way you can ally them all by running 2 lines of script at the end instead of currently where it could possibly bug and will re-ally everyone every time someone is added to team 2 (which is a waste of processor time as no everyone may be in the teams yet).
To get the lines outside the loop drag them to the gap below the root node of the loop (the actual loop statement) but before it indents for the looping code. They will then appear on the same line as the loop root but after the actual loop block.
0
You might want to mention approximate numbers of the effects.
So they are stunned permanently? By surviving you mean it has a percentage chance to kill stuff instantly? You need to be much more clear about all the abilities exact effects or you might not get what you want.
0
That is because that is an "event" not a "condition"?
This is the first time I am reading anything about periodic events. What job must be done periodically?
If you want to periodically spawn all units placed then use some kind of array system to track them. Use a 2 dimensional int array where each column represents the unit type spawned and each row the spawn point with the value being the number to spawn. You could use a boolean array in parallel to rows (via struct or a separate array) to keep track of which spawn points have units to spawn so that you do not bother checking the columns needlessly. The mapping of column to unit type could be done with a unit type array.
0
I have noticed a number of issues with your map.
As for the repawning... You sure everyone is hitting 0 supply? Are all the triggers firing?
0
Assign all units spawned at each point to a unit group (add them to the group). Before spawning new units, check if there is space in the unit group (number of living units in unit group < X where X is the number of units you want). This why no more than X can exist at a time.
You may need to flush dead units from the groups from time to time, I am uncertain if SC2 does this automatically and if not it could possibly be a leak of sorts.
You could also assign an integer to each spawn point to buffer "over spawns" so that you can spawn them at a later time if you wanted but that could change the dynamics of your game.
Ultimately making it some form of data driven system would be great. That way all spawns could be run from the same triggers and new spawns or spawn removal would be as easy as setting some variables. One approach for such a system would be an array of structs (forget what they are called in GUI) which each index represents a spawner. You set all indicies up at map initialization and then periodically check through each one spawning when appropriate. To spawn all you need is a location (where the spawn is), a group (the number of currently alive spawns) and possibly an integer (how many ticks until spawn) and another integer (how many ticks until respawn, the period). For over spawn support you would need an integer (how many spawns could not be spawned but wanted to).