1) No, a memory leak is when you lose reference to something and as a result can't get rid of it. If you want to keep something, like a Unit Group, for the entire game then that's perfectly fine and actually recommended. I should add that it depends on what that something is as well. Basic things like Integers, Reals, Booleans, Strings won't leak in GUI. You need to worry about Points, Unit Groups, Player Groups, and Special Effects.
An example, let's say you had a file on your computer's hard drive that was permanently "hidden" so you couldn't delete it but it was still taking up space. That would be a memory leak. But if you had access to that file, say it was sitting on your desktop, then at any time you can delete it and recycle it so it's NOT a memory leak. It's actually smart to store things in memory. That's why most systems have an Initialization/Setup trigger which create and store a bunch of data. At the exact moment that the data is created there's a performance hit, but after that initial hiccup you will see huge performance improvements because you can now access that data whenever you want instead of creating/destroying it over and over again.
2) You're already using Loops, for example when you do this:
-
Unit Group - Pick every unit in ShieldGroup and do (Actions)
-
Loop - Actions
^ That's a loop, easy as pie. Arrays are extremely simple as well, it's a way to use one variable to store a lot of data at once. The way you're using Custom Value/Ability Fields is basically the same way you would use an Array.
For example, this trigger can be greatly improved using an Array:
-
-------- let's track Player 1's heroes --------
-
Set Variable Player1_Hero1 = Paladin
-
Set Variable Player1_Hero2 = Archmage
-
Set Variable Player1_Hero3 = Mountain King
-
-------- let's track Player 2's heroes --------
-
Set Variable Player2_Hero1 = Blademaster
-
Set Variable Player2_Hero2 = Far Seer
-
Set Variable Player2_Hero3 = Tauren Chieftain
In our map, each Player controls 3 Heroes at a time, and we track those Heroes using the above Unit variables. Why is this bad design? 1) It creates a lot of variables and bloats our map. 2) It is very difficult to work with since we now have 3 variables per player to deal with.
How does an Array help fix this? Simple, we can combine all 3 of those Unit variables into one single Unit Array variable:
-
-------- let's track Player 1's heroes the smart way --------
-
Set Variable Player1_Hero[1] = Paladin
-
Set Variable Player1_Hero[2] = Archmage
-
Set Variable Player1_Hero[3] = Mountain King
-
-------- let's track Player 2's heroes the smart way --------
-
Set Variable Player2_Hero[1] = Blademaster
-
Set Variable Player2_Hero[2] = Far Seer
-
Set Variable Player2_Hero[3] = Tauren Chieftain
We've now reduced our variable usage from 6 to 2 and end up with the same exact result as well as the ability to give our Players a near infinite number of Heroes. This is smart and dynamic and opens up the door to many neat tricks that an [index] allows for. For example, let's kill a random hero that belongs to Player 1:
-
Unit - Kill Player1_Hero[Random integer number between 1 and 3]
Then by using a Unit Indexer we can push the power of our Arrays even further because we can now use the [Index] to represent an individual Unit.
3) Regarding the If Then Else statements, sorry for not going into detail. Here's a better example.
The trigger below is GOOD because we're asking two questions, is our Dying unit a Footman or a Rifleman, but we only ask the Rifleman question IF the unit wasn't already confirmed to be a Footman. Therefore, whenever a Footman dies, the bottom half of the trigger doesn't happen. There's no reason to ask a silly question like "Is it a Rifleman?" when you've already confirmed that it's a Footman. The less your trigger has to do the more efficient it will be:
-
Events
-
Unit - A unit dies
-
Conditions
-
Actions
-
Set Variable DyingUnitType = (Unit-type of (Dying unit))
-
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
-
If - Conditions
-
DyingUnitType Equal to Footman
-
Then - Actions
-
Game - Display to (All players) for 30.00 seconds the text: Efficiency!
-
Else - Actions
-
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
-
If - Conditions
-
DyingUnitType Equal to Rifleman
-
Then - Actions
-
Game - Display to (All players) for 30.00 seconds the text: Efficiency!
-
Else - Actions
This other trigger is BAD because we're asking both questions, was it a Footman or a Rifleman, even if we've already confirmed that it was a Footman. That's pretty dumb, a unit can't be two different Unit-Types at once, so doing it like this is a waste:
-
Events
-
Unit - A unit dies
-
Conditions
-
Actions
-
Set Variable DyingUnitType = (Unit-type of (Dying unit))
-
Actions
-
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
-
If - Conditions
-
DyingUnitType Equal to Footman
-
Then - Actions
-
Game - Display to (All players) for 30.00 seconds the text: NOT Efficient!
-
Else - Actions
-
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
-
If - Conditions
-
DyingUnitType Equal to Rifleman
-
Then - Actions
-
Game - Display to (All players) for 30.00 seconds the text: NOT Efficient!
-
Else - Actions
4) I was referring to the idea of storing Event Responses in variables when able. For example:
-
Events
-
Unit - A unit Starts the effect of an ability
-
Conditions
-
Ability equal to blah blah blah
-
Actions
-
Set Variable Caster = (Casting unit)
-
Unit - Set life of Caster to to (life of Caster + 100.00)
-
Unit - Create 1 Footman for (Owner of Caster) at SomePoint...
-
Unit - Add Critical Strike to Caster
In the above trigger we're referencing Caster 5 times in total. This is more efficient than referencing the Event Response (Casting unit) 5 times, because Event Responses are a slower operation. Referencing a variable is always faster. It can also make for cleaner and less buggy triggers.
However, if your trigger has a Wait action then sometimes it's better to use the Event Response since most of those will be tracked safely over time. Or, you can use a technique called
shadowing to turn your Variable into a sort of hybrid Local/Global variable temporarily which resolves this issue (most of the time).
? Are you referring to the calls for location and group destruction? Is that slowing the game or something?
![A]mun](/data/avatars/s/140/140771.jpg?1674379729){kind=avatar}
