Event - Unit dies, causing leaks/lag?

[StormChaser]

I got a question for a trigger I got in mind. However as I don't know a lot about what causes leaks I decided to ask you people for help. I got the overall picture of trigger in mind and how it'll function. However I am unsure of the Event - [Generic] Unit Dies. I can only imagine that as the trigger needs to check its conditions every time a unit dies, problems may arise.

Event
Unit Dies

Conditions
Unit Type of Dying Unit = (Custom Unit-type)

Actions
Player - Add 100 Gold to Player 1
Hero - Gain x Experience

I have been thinking about making it into a integer so that when x amount of Custom Unit-type is killed, the player will gain an extra reward. But I am not confident enough in my skill to try with integers.
I also got a version of this trigger which will work as a Repeatable Quest.

Event
Unit Dies

Condition
(Custom Unit_1) is Dead = True
(Custom Unit_2) is Dead = True
(Custom Unit_3) is Dead = True

Action
Turn On "Turning Quest In to NPC"
Turn Off "This Trigger"

Does these Events/Conditions/Action cause leaks? How should I solve that? I am sorry for not giving a proper GUI. The computer crashed while I was doing it and I lost the map so I'll have to re-make it. I am only experienced with GUI and simple triggers. Just FYI.

Another thing, is there some guide/post/etc. on here or around where I can get more information about what causes leak and how to avoid them/solve it?

 

[Chaosy]

no. that does not leak in any way

http://www.hiveworkshop.com/forums/triggers-scripts-269/things-leak-35124/
http://www.hiveworkshop.com/forums/...quick-tutorial-common-triggering-tips-190802/

 

[StormChaser]

Thanks for the answer! I took a look at that Things Which Leak post. It's a lot of posts in there and I find it a bit difficult to get the overall picture. But thanks anyway.

 

[nedio95]

There are a lot of posts and most of them are asking if something leaks.

Evrything which leaks is summed in the first post.

 

[ap0calypse]

Evrything which leaks is summed in the first post.

Everything that leaks and should be fixed*
Other things that leak are strings, triggers, weather effects, sounds, boolexpressions, hmm. Maybe more.
The thing is: they either shouldn't be fixed because it would ruin the game (e.g.: triggers), or you can't fix them and should just minimize their use (e.g.: strings).

Anyway, just stick to solving the things listed in the first post and you'll be good to go .

 

[StormChaser]

Everything that leaks and should be fixed*
Other things that leak are strings, triggers, weather effects, sounds, boolexpressions, hmm. Maybe more.
The thing is: they either shouldn't be fixed because it would ruin the game (e.g.: triggers), or you can't fix them and should just minimize their use (e.g.: strings).

Anyway, just stick to solving the things listed in the first post and you'll be good to go .

From what I have gathered Unit groups, Special effects, Pan camera, Pick Unit of Unit Type and do... and Regions/Locations are the ones which needs to be fixed, right? I did made a question there about "Unit Group - Pick Units."

 

[ap0calypse]

Almost right: you forgot to mention player groups.
This happens most often when you're sending messages to a player, such as:

• Game - Display to (Player group((Triggering player))) the text: Hello

^ Leaks.
(Don't forget: "All Players" doesn't leak!)

Pan camera, Pick Unit of Unit Type and do...

should never be used.
If you do: just fix them as you normally would, but it will still create a leak (this cannot be avoided).

 

[edo494]

how does exactly trigger leak?
just so I know what you mean

 

[Xonok]

how does exactly trigger leak?
just so I know what you mean

As I get it it's created and never deleted. Usually it's no problem(obviously), but if you have a system that creates triggers, then it might be.

 

[edo494]

DestroyTrigger

 

[StormChaser]

Almost right: you forgot to mention player groups.
This happens most often when you're sending messages to a player, such as:

• Game - Display to (Player group((Triggering player))) the text: Hello

^ Leaks.
(Don't forget: "All Players" doesn't leak!)


should never be used.
If you do: just fix them as you normally would, but it will still create a leak (this cannot be avoided).

What about when use Player Groups to set alliances or when I wants to show a message e.g. a Quest Update for a group of players? Does it still leak? Can I solve the leak without destroying the group? If I have set an alliance between two player groups won't a DestroyPlayerGroup script destroy that alliance? Can I keep the group active for future messages without having to destroy it?

How do I fix Pan Camera and Pick All Units of Unit-Type?

Sure, I don't think I'll use Pick All Units of Unit-Type anyway. But I do use Pan Camera for Cinematics. Does the same apply to Pick All Units in Region? That it leaks?

 

[ap0calypse]

Hm, I'll try to explain this as best as I can. It will be a simplified explanation, but the post may be a bit long .
Stuff leaks the moment it has been created, but you can't access it anymore.

• Unit Group - Pick every unit in (Units in (Playable map area)) and do (Actions)
  • Loop - Actions

Here, you create a unit group. After creation, you can never access that exact unit group anymore.
You can still use the function of course, but some units may have died/spawned, so it will just create a new group next time too (even if all the units are exactly the same: Warcraft doesn't know this, so it will create a new unit group every time you use that function).

You may not be able to access it, but Warcraft will still remember that value!
So every time you use a unit/player group, location, special effect and so on, Warcraft will remember all of that until the game is over.
The more stuff it has to remember, the harder it becomes to keep functioning properly.
After a while, players will experience heavy lag because of this.


So what you need to think about is this: "Can I still access this after using it?"
If the answer is no, then it leaks. Unless, of course, you've already fixed it .

Here are a few examples:

Examples

Example 1:

• Spawn
  • Events
    • Time - Every 2.00 seconds of game time
  • Conditions
  • Actions
    • Unit - Create 1 Footman for Player 1 (Red) at (Center of Spawn <gen>) facing Default building facing degrees

Question: Can you still access the value "Center of Spawn" after this?
Answer: no (which means it leaks).
Explanation: Sure, you can still use "Center of Spawn <gen>", but the region might have moved somewhere else!
Since Warcraft doesn't know if the region has been moved or not, it HAS to assume that it has (otherwise moving the regions would bug), so it has to create a new location every time.
The original location can never be accessed again and is leaking.

Example 2:

• Init
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Set SpawnLoc = (Center of Spawn <gen>)

• Spawn
  • Events
    • Time - Every 2.00 seconds of game time
  • Conditions
  • Actions
    • Unit - Create 1 Footman for Player 1 (Red) at SpawnLoc facing Default building facing degrees

Question: Can you still access the value "Center of Spawn" after this?
Answer: yes (no leak).
Explanation: the value "SpawnLoc" never changes. Even if the region moves, the value inside that variable will still point to the original location of the region.
Because it still points to the original location, no new locations need to be created.

Unit/Player groups do have an extra difficulty.
Because of the way things work, this leaks:

• Unit Group - Add all units of (Units in Spawn <gen>) to UnitGroup

You can still access it at any time (in the variable "UnitGroup"), but the group "Units in Spawn" is a newly created unit group that never gets destroyed.

This is the fix (only works for unit groups!):

• Custom script: set bj_wantDestroyGroup = true
• Unit Group - Add all units of (Units in Spawn <gen>) to UnitGroup

So about your player group problem: if you set the allies in a player group at the start of the game, then it won't leak and you'll never have to destroy the player group.

How do I fix Pan Camera and Pick All Units of Unit-Type?

Not possible.
Only "Pan Camera as Necessary" is like that though, the other 2 "Pan Camera"-functions can be fixed (regular location leak fix).

 

[StormChaser]

Thanks a lot for this ap0calypse! I am very grateful and relived.

Edit. So the bj_DestroyGroup(ugd_Variable) = True does destroy the Variable Unit Group while bj_wantDestroyGroup = True only destroys the temporary Units in Region group? If I understand correctly.

 

[edo494]

theres no bj_DestroyGroup(udg_group) = true
there is only DestroyGroup(udg_group), which is function and so It should be called at the end of the trigger

 

[ap0calypse]

It's as edo says.

set bj_wantDestroyGroup = true destroys the next group that gets created (and only the next group).
call DestroyGroup(udg_Variable) destroys a group of your choice (the one stored in the variable).

Be careful with caps though: "True" does not exist and will create an error, it must be "true" (lower-case).

 

[StormChaser]

Thanks! I realized my error when it became a script error due to "Expected set". I changed it and it works fine now.

OK so I only write Custom Script: call DestroyGroup(ugd_Variable) for a specific group and Custom Script: set bj_wantDestroyGroup for the next group? (That was what confused me before since I thought it destroyed all groups... I need to edit my trigger again then.)

I wrote a big True at first but then I checked here to see if I did wrote correctly which I didn't. So I changed it.

 

[edo494]

the set bj_wantDestroyGroup = true is for

• Unit Group - Pick every unit in (Units in (Playable map area)) and do (Actions)
  • Loop - Actions

thats because when converted to jass, it is:

function ForGroupBJ takes group whichGroup, code callback returns nothing
    // If the user wants the group destroyed, remember that fact and clear
    // the flag, in case it is used again in the callback.
    local boolean wantDestroy = bj_wantDestroyGroup
    set bj_wantDestroyGroup = false

    call ForGroup(whichGroup, callback)

    // If the user wants the group destroyed, do so now.
    if (wantDestroy) then
        call DestroyGroup(whichGroup)
    endif
endfunction

so basically if the bj_wantDestroyGroup is set to true, the next group created this way will be destroyed when the itteration was done

while you still can do Set someVariable = Units within .... ... ....
and when you want to destroy group like this, you do DestroyGroup(udg_someVariable)

That means, that if you need that group for later uses, you dont destroy it and create it again

 

[StormChaser]

OK, thanks!

 

[SA Dashie]

Just another little additive.
The player groups under 'presets' for example 'Player Group - Player 3 (Teal)' and 'Player Group - Neutral' etc also don't leak.