Hello me again, im just wondering how to compose several triggers into one, instead of having 8 separate triggers for each player.
Please dont yell at me for being a bad programmer, i self taught at the age of 9 im now 15, i never learnt how to do the more advanced stuff, which is why im looking for help now as my games are becoming overly laggy with only a few units.
What iv done is for the revivals just look for a specific unit whenever a unit dies but for each trigger making it so the unit it is looking for belongs to player 1,2,3,4 etc. Iv heard of rows and columns and stuff like that for variables but i could never figure them out im not sure if they could help here.
For the player deaths iv made 3 triggers, one to add units to a unit group of every players units for when the player loses and a group of the units a player cannot have die. The trigger shown in the second picture is the last trigger when the player doesn't have those pictures and looses. These 3 triggers are for all 8 players, so whenever a unit is made or dies 8 triggers are having to compare the units, and the game is just becoming way too laggy.
Could someone please show me how i could use columns and rows or something to fix this? i very well know i might have to change how i do triggers altogether.
Variables can be put into arrays and actions can be applied using the pick each player function because it acts like a loop. A normal variable is 1X1, a single value that can be called upon. Arrays are 2-D variables that can go from 1X2 to 1X99 in SC2. Players are in the form of an integer, player 1 will equal the value 1 if called upon. Thus we can use this information to store each individual person's values in an array. Slot 4 in an array will have the value of player 4. Below is an example.
Here we can see my declaring the array as a 1X8, this is because I know that there are 8 people in the map.
Here we can see that I picking each player within the player group users. Every human player was added to the user player group upon initialization, this is because I have AIs which I don't want this trigger to apply to and if I tried to put player 9 (AI) into the array because it is only declared to be a 1X8 the trigger will break. Moving on the pick each player loop will begin with equal picked player to the value 1. It will assign HeroValue[1] = 50. It will then move on to the action to display the HeroValue[1] to the player 1. Finishing the loop it will then move on and assign HeroValue[2] = 50 and displays the value 50 to player 2 and so on until it has run out of players in the user player group.
It seems like you made player 1 into their own team so you can reference them in a player group, instead of that use the convert player to player group function. Also use arrays (or the data table if you want to be cool).
These 3 triggers are for all 8 players, so whenever a unit is made or dies 8 triggers are having to compare the units, and the game is just becoming way too laggy.
In order for 8 triggers firing on unit death to cause performance problems you will need to have hundreds of units dying every frame, which itself would be a much bigger performance problem.
I recommend testing the map with trigger debugger/profile enabled and getting it into a performance problem situation and checking the profile results to see which triggers are eating up the most time. Optimize those triggers.
Data can also cause performance problems. Let us not forget the collision system SC2 uses will always cause performance problems if too many units constantly push into each other.
In order for 8 triggers firing on unit death to cause performance problems you will need to have hundreds of units dying every frame, which itself would be a much bigger performance problem.
I recommend testing the map with trigger debugger/profile enabled and getting it into a performance problem situation and checking the profile results to see which triggers are eating up the most time. Optimize those triggers.
Data can also cause performance problems. Let us not forget the collision system SC2 uses will always cause performance problems if too many units constantly push into each other.
Imperialgood where do i get a debugger to see whats causing the prolem and what in data specifically can cause slow performance? I dont think it could be from the units pushing against eachother, all units wander automatically and they will attack eachother usually unless they are allied, so i doubt thats the problem.
Enable the trigger debugger/profiler. This is done in the editors preference menu. Do note, testing must start StarCraft II in windowed mode in order for the debugger/profiler to be an option. Additionally the debugger/profiler will slow down Galaxy script performance due to extra overhead, however it will do so in a way that you can still find triggers to optimize.
Among its many views are ones listing how many times a trigger has run, how must time was spent executing the trigger thread, how many times each function was called and how much time was spent inside each function. It can also allow you to stop and inspect your triggers anywhere you want. Advance your map until performance is a problem and then check what triggers are using the most time, that is where you will want to optimize. The time must also be non-trivial, as few hundred ms over 16+ minutes is mostly trivial.
The hellion weapon is an example of a resource intensive weapon. It uses multiple search areas to hit units in a line. If you allow 100 hellions to attack another 100 hellions the game frame rate can hit single digits.
Like wise simply having hundreds of units constantly moving will also cause performance problems. If you are making an RPG/survival style map where units need to constantly move, possibly in a random like way, then consider only having these units nearby players. Such wandering units that wander too far away from the player are removed from the game, or moved closer to the player. Like wise as the player moves new monsters might be appear. As long as all monster spawning and teleportation occurs outside of vision the player will be none the wiser of the trickery going on. Instead of a lot of small units, fewer bigger units could also be used.
Guys ok so what iv done is iv done the arrays for the variables and for the triggers im just putting where it says like 'variable[0]' iv put variable[owner of triggering player]. im just checking would this work? Im not sure weather to use this or triggering player.
it seems to work logically but idk what else i would put if those dont work.
Using arrays to map a player to a value is a good idea. I recommend owner of the appropriate unit.
For some events triggering player has a special meaning. For example with learn, cast or order events the triggering player is actually the player who issued the original order. This may or may not be the owner of the unit as it will return other players if unit control is shared with them and used to trigger the event. As such owner of triggering unit is often more desirable as it assures the intended player is selected.
What I recommend doing is creating a data entry type (compiles to struct in galaxy script) and making an array of that data entry type which maps player to a data entry. This way per player variables can be changed by changing the data entry instead of having to deal with a dozen different arrays. This improves maintainability.
Hello me again, im just wondering how to compose several triggers into one, instead of having 8 separate triggers for each player.
Please dont yell at me for being a bad programmer, i self taught at the age of 9 im now 15, i never learnt how to do the more advanced stuff, which is why im looking for help now as my games are becoming overly laggy with only a few units.
What iv done is for the revivals just look for a specific unit whenever a unit dies but for each trigger making it so the unit it is looking for belongs to player 1,2,3,4 etc. Iv heard of rows and columns and stuff like that for variables but i could never figure them out im not sure if they could help here.
For the player deaths iv made 3 triggers, one to add units to a unit group of every players units for when the player loses and a group of the units a player cannot have die. The trigger shown in the second picture is the last trigger when the player doesn't have those pictures and looses. These 3 triggers are for all 8 players, so whenever a unit is made or dies 8 triggers are having to compare the units, and the game is just becoming way too laggy.
Could someone please show me how i could use columns and rows or something to fix this? i very well know i might have to change how i do triggers altogether.
Thanks, happyface
Use the pick each player function and rather than referring to player 1 specifically you would refer to picked player.
what about all the actions and variables though? how do i put the variables into separate groups for the different players?Could u give me an example?
thanks
Variables can be put into arrays and actions can be applied using the pick each player function because it acts like a loop. A normal variable is 1X1, a single value that can be called upon. Arrays are 2-D variables that can go from 1X2 to 1X99 in SC2. Players are in the form of an integer, player 1 will equal the value 1 if called upon. Thus we can use this information to store each individual person's values in an array. Slot 4 in an array will have the value of player 4. Below is an example.
Here we can see my declaring the array as a 1X8, this is because I know that there are 8 people in the map.
Here we can see that I picking each player within the player group users. Every human player was added to the user player group upon initialization, this is because I have AIs which I don't want this trigger to apply to and if I tried to put player 9 (AI) into the array because it is only declared to be a 1X8 the trigger will break. Moving on the pick each player loop will begin with equal picked player to the value 1. It will assign HeroValue[1] = 50. It will then move on to the action to display the HeroValue[1] to the player 1. Finishing the loop it will then move on and assign HeroValue[2] = 50 and displays the value 50 to player 2 and so on until it has run out of players in the user player group.
It seems like you made player 1 into their own team so you can reference them in a player group, instead of that use the convert player to player group function. Also use arrays (or the data table if you want to be cool).
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
In order for 8 triggers firing on unit death to cause performance problems you will need to have hundreds of units dying every frame, which itself would be a much bigger performance problem.
I recommend testing the map with trigger debugger/profile enabled and getting it into a performance problem situation and checking the profile results to see which triggers are eating up the most time. Optimize those triggers.
Data can also cause performance problems. Let us not forget the collision system SC2 uses will always cause performance problems if too many units constantly push into each other.
Thanks guys i think i get what ur all meaning now. I should be able to change them into more efficent triggers now, ty.
Enable the trigger debugger/profiler. This is done in the editors preference menu. Do note, testing must start StarCraft II in windowed mode in order for the debugger/profiler to be an option. Additionally the debugger/profiler will slow down Galaxy script performance due to extra overhead, however it will do so in a way that you can still find triggers to optimize.
Among its many views are ones listing how many times a trigger has run, how must time was spent executing the trigger thread, how many times each function was called and how much time was spent inside each function. It can also allow you to stop and inspect your triggers anywhere you want. Advance your map until performance is a problem and then check what triggers are using the most time, that is where you will want to optimize. The time must also be non-trivial, as few hundred ms over 16+ minutes is mostly trivial.
The hellion weapon is an example of a resource intensive weapon. It uses multiple search areas to hit units in a line. If you allow 100 hellions to attack another 100 hellions the game frame rate can hit single digits.
Like wise simply having hundreds of units constantly moving will also cause performance problems. If you are making an RPG/survival style map where units need to constantly move, possibly in a random like way, then consider only having these units nearby players. Such wandering units that wander too far away from the player are removed from the game, or moved closer to the player. Like wise as the player moves new monsters might be appear. As long as all monster spawning and teleportation occurs outside of vision the player will be none the wiser of the trickery going on. Instead of a lot of small units, fewer bigger units could also be used.
Ok thank you imperial good ill definitely do this
Guys ok so what iv done is iv done the arrays for the variables and for the triggers im just putting where it says like 'variable[0]' iv put variable[owner of triggering player]. im just checking would this work? Im not sure weather to use this or triggering player.
it seems to work logically but idk what else i would put if those dont work.
Using arrays to map a player to a value is a good idea. I recommend owner of the appropriate unit.
For some events triggering player has a special meaning. For example with learn, cast or order events the triggering player is actually the player who issued the original order. This may or may not be the owner of the unit as it will return other players if unit control is shared with them and used to trigger the event. As such owner of triggering unit is often more desirable as it assures the intended player is selected.
What I recommend doing is creating a data entry type (compiles to struct in galaxy script) and making an array of that data entry type which maps player to a data entry. This way per player variables can be changed by changing the data entry instead of having to deal with a dozen different arrays. This improves maintainability.
Thank you so much imperial good you've helped me a tonne, happy new year and see u later :D.
PS i have no ieda what ur talking about with the galaxy script, but ill worry about that later.