Things That Leak

[darkrider]

well... i think that there is no difference... but i always use call DestroyGroup(udg_blabla)

 

[Razorbrain]

set bj_wantDestroyGroup = true does work, but you have to make a new function for every group

• Spell
• Events
• Conditions
• Actions
  • Custom script: set bj_wantDestroyGroup = true
  • Unit Group - Pick every unit in ......
  • Custom script: set bj_wantDestroyGroup = true
  • Unit Group - Pick every unit in ......

 

[KaiserG]

thanks a lot, thats very useful. +rep for u!

 

[Super-Sheep]

This isnt actually a leak, but I didnt wanted to create a new thread for it. So:
I've seen many mappers to use "Set Caster = Casting Unit", "Set Target = Target of Ability being cast" and so on.

Does this optimize and make map faster or something, or it just makes it to look cleaner and easier to read?

 

[Razorbrain]

i think it just makes it cleaner, but im not an expert on this, i only know how to fix things

 

[spiwn]

My personal theory:
Target of Ability being cast is a function. Function calls are slower than variable calls.
So calling a variable would be faster then calling a function, but you have to make the variable, than call the function to get a value for the variable, which would slow down things. So in conclusion if you intend on using the value a lot, store it in a variable, but if you are going to use it once or twice, just use the function.
P.s. Using Casting Unit is stupid as it returns triggering unit but it a function call therefor slower than just using triggering unit.

 

[Razorbrain]

still, the difference of the speed is too tiny for it to matter on a normal map

 

[Herman]

Aye, but it does make a difference if you use periodic effects.

 

[darkrider]

besides... waits wont let you use "casting unit" and you will be forced to use variables

 

[Razorbrain]

Aye, but it does make a difference if you use periodic effects.

yes, becouse calling an event function in a periodic event is so easy

 

[Need_O2]

besides... waits wont let you use "casting unit" and you will be forced to use variables

or you can use Triggering Unit (ya its local somehow)

 

[Herman]

yes, becouse calling an event function in a periodic event is so easy

Forgot about that

Still the ForGroup() function, [EnumUnit()] and events that happen very quickly could still effect it

 

[Vex]

I have a question about special effects and leaks.
Is it correct that the following is impossible to do without causing leaks?

A trigger creates 10 special effects and store them in a special effects array.

Another trigger later goes through that array and destroys them.

I know you can just create 10 triggers that each create their own special effect, waits until they are supposed to be destroyed then get no leaks but that would make it a lot more complicated as each effect are supposed to be removed/replaced by others at different times during the map I'm making.

EDIT: By using big numbers and the task manager for simulating, I noticed that the clean up array only restores about 5% of the memory used in the first array :/

 

[Herman]

You will probably want to look into vJASS, it deals alot with data storage for special effects that have to do with timing

You can easily, very easily store 10 special effects and destroy them later in vJASS

 

[Vex]

Thanks for the tip.

 

[SanKakU]

ok, well, it seems to me like you are supposed to destroy locations and unit groups and those kinds of things...and i thought you were supposed to null them also...but someone said you don't null unit groups?

so what do you null and what do you destroy? and like, i'm pretty sure locations need to be nulled...but i saw on someone's map they are not nulled and it's a good triggered map so i don't understand.... some help? it is very confusing.

what needs to be nulled and what needs to be destroyed? and is there an order to nulling and destroying when you have to do both?

err...let me see if i got this right...i just read the msg by spiwn again...

no global variables need nulling... so that means just local variables need nulling right? well...oops.

so how do you treat the local variables? how does the nulling and destroying work there?

are you supposed to use the bjwantdestroy variable thing for the local/global? or is that basically the same thing as the other destroy variable function?

 

[Herman]

ok, well, it seems to me like you are supposed to destroy locations and unit groups and those kinds of things...and i thought you were supposed to null them also...but someone said you don't null unit groups?

so what do you null and what do you destroy? and like, i'm pretty sure locations need to be nulled...but i saw on someone's map they are not nulled and it's a good triggered map so i don't understand.... some help? it is very confusing.

what needs to be nulled and what needs to be destroyed? and is there an order to nulling and destroying when you have to do both?

err...let me see if i got this right...i just read the msg by spiwn again...

no global variables need nulling... so that means just local variables need nulling right? well...oops.

so how do you treat the local variables? how does the nulling and destroying work there?

I'll try to explain it, I might even write a tutorial on it. Handles are objects in the game, big pieces of data. They take alot of the CPU's power/speed/energy/memory/whatever you'd like to call it. To avoid using too much memory, programmers destroy/remove these handles. When the handle is not removed when your finished using it, it is considered a leak. Now the confusing part is 'nulling'. Due to how WarIII's system runs, the handles will not be removed if variables are pointing to it. There is an explanation as to why this occurs, but its not to important. Please also note about variables, variables simply 'point' to the object, they are not the actual object (the handle is).

Sometimes you don't need to destroy handles if your re-using them (if you don't destroy them, you don't need to worry about 'nulling' them). With certain variables, they say you don't need to null them, because you are constantly re-using them (in other words, your pointing the variable to something else [which we usually use null for], thus allowing the handle to be removed appropriately). That should about cover it.

 

[SanKakU]

well anyway obviously what spiwn said is totally wrong...i don't understand what you're saying but it doesn't sound like much...

but i went ahead and took out all the nulling for the global variables and instead of the annoying black screen bug that sometimes happened to players and usually happened in the replays...i got everyone disconnected within the first ten minutes of every game!

that is extremely annoying and as you can see...it disproves what he told me.

if Herman or whoever honestly knows what's what then PLEASE look at my map and explain to me how i need to be editing these triggers.

the nulling the global variables apparently is necessary, at any rate...because without it my map disconnects everyone. but is the overnulling what's causing the black screen bug? how come no one has ever explained what that is? no one seems to know what it is, as if i'm the only one running into it.

do a full house on my map and watch the replay after the game.
it should do a weird black screen sometimes and maybe even crash. but at least it operates better than no nulling the globals.

 

[spiwn]

well anyway obviously what spiwn said is totally wrong...i don't understand what you're saying but it doesn't sound like much...

but i went ahead and took out all the nulling for the global variables and instead of the annoying black screen bug that sometimes happened to players and usually happened in the replays...i got everyone disconnected within the first ten minutes of every game!

that is extremely annoying and as you can see...it disproves what he told me.

if Herman or whoever honestly knows what's what then PLEASE look at my map and explain to me how i need to be editing these triggers.

the nulling the global variables apparently is necessary, at any rate...because without it my map disconnects everyone. but is the overnulling what's causing the black screen bug? how come no one has ever explained what that is? no one seems to know what it is, as if i'm the only one running into it.

do a full house on my map and watch the replay after the game.
it should do a weird black screen sometimes and maybe even crash. but at least it operates better than no nulling the globals.

The only one who does not know "what it is" is you.
You are skimming the text. There already is(are) tutorial(s) on variables.
Like this one. But people do not seem to go in the tutorial section these days.
No I am not wrong. Global variables need not to be nulled, but they have to be destroyed removed(there are some exceptions like recycling or using only a limited number of variables - like 1! unit group).

It has been said many times over, so I am not going to write it from scratch.
If you want to know about handles and pointers here:

To fully understand why global variables do not have to be nulled you would have to understand what a variable of type any handle(unit, group and etc - everything except integer, real, boolean, string( I may miss something) is.
Lets say we have a variable of type unit.
Since this is a handle, not one of the basic types, the variables does not carry all the data about the unit.
Ah, confusing. For example an integer variables stores the actual integer. But with a unit(handle) that would be impossible(there is a lot of data connected with it- position height, health and etc). So blizzard most probably made their own structures - unit, group and etc.
When you create a unit, the structures is created. When you store the unit in a variable a pointer/index/address to that structures is stored in the memory(it is a way to show where in the memory the data for that unit is stored). So when you use something like
set temp_unit=bj_lastcreatedunit
War3 retrieves that address(which is a number(integer), but like 0x9002305 (example only) ) and stores it.
When you call that temp_unit war3 finds what address is stored in the variable and refers to the structure at that adress.
So every variable of type handle is actually an integer that shows the address of some structure, but a bit different, because war3 does not erase it.
The H2I function(rather famous, if you have not heard of it search(most systems use it)) uses this, and when you use something like H2I(temp_unit) it will return the address/pointer/index that is stored in temp_unit.
Here there is one important thing to learn - while an address of some structures exists, anywhere - local or global, that structure address cannot be used again, even if the actual structure is destroyed. And because addresses get used and never freed, the address of the next created structure will be bigger. All those local variables that point to some structure will take memory. Addresses will continue to increase, memory taken by pointers will increase, resulting in lag, and eventually in a game crash.

So lets examine local and global variables.
If you use a local and do not null it, at the end of the function you will no longer be able to access it - change it, erase it or whatever. And since it is pointing to some structure, that address cannot be used ever again, so you must null it.
But when you use globals you can always access that variable.
So:
set udg_temp_unit = Blah
It stores some address in udg_temp_unit. Now you would think that this is the same as a local variable. Well you are not wrong - again until the pointer is not removed, it will use up an address.
Ah, but with globals, you can access them again:
set udg_temp_unit= Blah2
Now udg_temp_unit is assigned a different pointer, but the old one is erased, so the index is freed.

I have realized this, by reading a lot of tutorials, examining the H2I and studying user structures(vJass). Yes it is rather true.
I explained it the simplest way I could. I will not be surprised if you do not understand it from the first time. Whether you understand it ever depends only on you(some people just think other ways ).
If you want to understand this/ become proficient with jass, I suggest you keep it, read tutorial, practice and read it again(until you understand it).
Note that understanding this is not really necessary to become a good "jasser". You actually can just remember this: Null locals, do not null Globals.


Only string, real, integer, code, boolean are not "structured". They are basic. I think they are included in most programming languages.
Everything else is a structure of those( in all languages).
Player structures probably include IPs, handicap, color, player name etc.
Units, groups, locations, player and etc are Handles (that is what blizzard calls them ( to fully understand what a handle is a very advanced thing must be learned - Interfaces, but since I have not even started learning about those, I cannot explain this to you)).
Since Blizzard did no and still do not wish to share how they have created handles this structure theory is just a smart guess. People do not call them structures, that is just something I figured would be most suitable to explain about them.

Because handles have an internal reference counter which is increased when they're referenced and decreased when they are dereferenced, and if it's >0 their handle id can't be recycled.

We cannot be 100% sure - it is illegal to peak in blizzards code.
But we can test it:

function U2I takes unit u returns integer
return u
return 0
endfunction

function Trig_testvars_Actions takes nothing returns nothing
local integer i=0
local integer max=0
local integer ti
local unit array u[1000]
loop
exitwhen i==1000
set u[i]=CreateUnit(Player(0),'hfoo',0,0,0)
set ti=U2I(u[i])
call RemoveUnit(u[i])
//set u[i]=null //enable this for second test
if(max<ti) then
set max=ti
call BJDebugMsg("Current address is " + I2S(max))
endif
if((i-(i/5)*5)==0) then //To prevent lagg
call TriggerSleepAction(-1)
endif
set i=i+1
endloop
endfunction

Result for first test should be 1000 numbers displayed on screen. And from second, only 5(because the handle index cannot be freed while war 3 is executing something else(like this function), so when the trigger sleep action is called wc3 moves on does things(like freeing handle indexes) and comes back here to continue).

I wrote that a long time ago for someone else.
Because I am sure you are going to miss it, I am gonna take it out of the quote:
So lets examine local and global variables.
If you use a local and do not null it, at the end of the function you will no longer be able to access it - change it, erase it or whatever. And since it is pointing to some structure, that address cannot be used ever again, so you must null it.
But when you use globals you can always access that variable.
So:
set udg_temp_unit = Blah
It stores some address in udg_temp_unit. Now you would think that this is the same as a local variable. Well you are not wrong - again until the pointer is not removed, it will use up an address.
Ah, but with globals, you can access them again:
set udg_temp_unit= Blah2
Now udg_temp_unit is assigned a different pointer, but the old one is erased, so the index is freed.

 

[SanKakU]

The only one who does not know "what it is" is you.
You are skimming the text. There already is(are) tutorial(s) on variables.
Like this one. But people do not seem to go in the tutorial section these days.
No I am not wrong. Global variables need not to be nulled, but they have to be destroyed removed(there are some exceptions like recycling or using only a limited number of variables - like 1! unit group).

saying what you are saying is fine if i could understand what you're talking about...please give me some examples!
like, what are those exceptions.
and it's not like i don't read the tutorials. it just so happens that alot of the information in them is irrelevant and hard to understand most of the time. especially annoying is lack of examples or them not showing examples properly. one of my biggest gripes is when they say this or that and i don't know what 'this' or 'that' is that they are referring to.
so like i said, please go over my map and give me examples of what destroying and nulling needs to be done. i'll check out that link for that tutorial you put in there in the meantime.

your way of explaining it was wrong, regardless of whether you know what is what, you have a horrible time explaining it.

edit: so that's what a widget is...lol cool, i learned one useful thing at least.
yeah everytime these guys explain something hard to understand they don't use an example, so i don't understand it. then, when they explain something even harder to understand they do use an example and don't explain the example very well.
ok i also learned != is not equal to. well, that's about it. there was a lot of important information in that tutorial and i didn't really understand it.

ok, i'm looking over a tutorial that i've read before and noticing that perhaps there are still more variables that are leaking...like my items. i am using items alot now so maybe those are leaking...i'll look into that. hmm...nope, i can't remove items variables. weird. oh there's a destroy item pool function too.
edit2: whoa whoops i was using the standard world editor, that's why it wouldn't let me remove the items, lol...stupid standard world editor. why doesn't blizzard update that piece of trash?

 

[spiwn]

saying what you are saying is fine if i could understand what you're talking about...please give me some examples!
like, what are those exceptions.
and it's not like i don't read the tutorials. it just so happens that alot of the information in them is irrelevant and hard to understand most of the time. especially annoying is lack of examples or them not showing examples properly. one of my biggest gripes is when they say this or that and i don't know what 'this' or 'that' is that they are referring to.
so like i said, please go over my map and give me examples of what destroying and nulling needs to be done. i'll check out that link for that tutorial you put in there in the meantime.

your way of explaining it was wrong, regardless of whether you know what is what, you have a horrible time explaining it.

edit: so that's what a widget is...lol cool, i learned one useful thing at least.

I beg to differ. You are the first to complain about my way of explaining and you seem to complain about all tutorials. Logically I come to the conclusion that the problem is not with me, not with my explaining, not with all the tutorials, but with you.
An example ... hah.
I was right
I knew you would miss it and I "highlighted" it. And yet again you missed it...

You are skimming the text.

You missed the single most important example. You have learned what a widget is, but that was a personal tutorial on handles (wtf).

Read it, while paying attention to it. This is not something you just have to read without understanding it.

In my previous post I have given you all the information you need to understand what a handle is. Only that information, in the simplest way possible. It is stripped from any connection to Objects, yet it is only about them, in order to make it very simple. Heck a person with basic programming knowledge - primitive variables and memory, and maybe some logic would be able to understand it. I have to admit that it is not very systematized, but it is understandable.

My guess is you do not have any idea what you are doing while triggering. To you "remove", "destroy" and etc are just some abstract terms without any meaning, but they do have.

Read this when you understand what destroy means:
Guess when you do not destroy a global handle ... when you are going to use it again.

 

[darkrider]

if you have a basic knowledge of programming you understand in deep what you are doing... if you dont... you do it by heart coz people say it (im that case... i started doing leaks removal coz people say it and my map got a lot better... later i started studying a career regarding rogramming so now i understand a little bit more, even though im still very basic)

What you need to know is that you must remove Unit groups when you are gonna use them in a spell trigger IE: if you pick every unit in range, etc
IE of when you are not gonna destroy a unitgroup is for ie you created a dummy unitgroup because you dont want your dummys to be affected by some trigger

you need to remove locations ALL OF THEM NO MATTER WHAT

you need to remove regions when created via triggers (also need to remove points in pre-existant regions coz those are LOCATIONS)
you MUST NOT remove pre-placed regions coz those are CONSTANTS not VARIABLES

you need to destroy playergroups when created via triggers (the same as unit groups) but you MUST NOT destroy ALL PLAYERS coz that is also a constant

For further knowledge read tutorials about handles (but nulling them for IE: units is not THAT important coz the will be replaced but LOCATIONS, UNIT GROUPS, PLAYER GROUPS AND REGIONS are VITAL to be removed

If you want an example of a map full of intentional leaks i can give you one and you can tell me what happens to you


guess thats all

PS: sounds MSUT NOT be removed coz those are also CONSTANTS

 

[SanKakU]

"If you want an example of a map full of intentional leaks i can give you one and you can tell me what happens to you "

you mean you want to show me a training map or something? alright, i guess. i'll try whatever.

and spiwn, your posts make less sense than the tutorials, and trust me, i tried really hard to understand every single tutorial i've read. your posts are definitely another story. furthermore, i understand the part about global being similar to local, what i don't get isn't the difference between local and global...it's about what needs to be done with what beyond that simple difference.

for example...how many variables should i use of each type? should some/all/none of them have arrays? what factors would influence these things? is it good to have a lot of variables? is that better than fewer? what are general rules to avoid memory leak involving all this?

like, previously, i would put everything in one point for casting of spells at a target location or something like that right? that is it would all be the same variable called point, but now i wonder if since it is a global variable, it is getting used simultaneously and that's causing problems...that's just one example of the minefield in my way of trying to make my map memory leak free. i guess for the most part...what mostly leaks is variables, right? improperly using them, that is...

anyway...as for spiwn, could you please explain this sentence?:
Global variables need not to be nulled, but they have to be destroyed removed(there are some exceptions like recycling or using only a limited number of variables - like 1! unit group).

what is this 1! unit group? and what are the exceptions, and what is this recycling?

and why do you feel like you have to be insulting? a widget is a type of handle...right? so isn't that why they put it in the handle tutorial? psh i don't know but i know a widget like a destructable, an item and like a unit...that's about all i know from all that.

and this sentence...

Read this when you understand what destroy means:
Guess when you do not destroy a global handle ... when you are going to use it again.

huh????? seriously...where's Herman or whoever when you need him?

so i guess the basics of what i need to know might be things like...
so i have a trigger whose events fire often, and then the trigger uses a global variable.
should that global variable be different from every other global variable? i'm guess that is the case. now, since this trigger is fired often and the variable is thus changed alot, does that mean that since the variable IS different from every other variable that not destroying and nulling it is ok? now there are exceptions, right? like locations, right? and what about unit groups? etc... kinda like what dark rider said above eh? am i on the right track at this point or am i still missing something?

 

[spiwn]

Argh... this is gonna be a hard one. As I said(several times) all the info is there.

But anyways:
! is the mark for only. 1! means one and only one.
Using a single group - create it at map initialization, then in every trigger use it - add units to it with the Group Enum functions, do some actions with the group and clear it at the end of the trigger.
Recycling is when you only use a limited number of handles of some type. For instance timers. You use lets say only 100 timers in your map. When you are done with one of them, you call a function that pauses it and "frees" it. So instead of creating and destroying timers all the time, you create 100 and then restart them.

Is it an insult to say that one does not want to understand what he ask others to teach him. Because if you wanted, you would already know. My "personal tutorial" has been tested and proven understandable.

Widgets are a subgroup of handles, but widgets are a whole lot different than handles. Only important thing about handles is indexing, destroying them and nulling. And widgets are ... just things you can actually see in the map. They do not get their index as widgets, but as handles. They are a child of handles, they extends handles. So they have nothing to do with this "issue" and yet you learned about them.

You asked for the exceptions I mentioned. So I told you. You do not destroy a global handle variable when you are going to use that very same handle again. Like having global variables for each hero and etc.

As I said, you have no idea what you are making triggers.
Triggers are not executed simultaneously. Wc3 can't do that. So if your trigger does not have a wait and it uses global variables it will work fine.
So using variables as temp_point temp_unit and etc is fine and normal for GUI. And you only have to have about 1,2 such variables in your entire map. More than one for triggers where you need to store two points(locations) (for instance).
What darkrider said is a general guide which variables to destroy. It ain't wrong, but it is not complete, because all handles you are not going to use anymore should be destroyed (or recycled). When you create a unit group with "set temp_group= Unit in 500 range of temp_point1" than you use the group, like pick all units in group and do actions, When you are done with the group you use "call DestroyGroup(g)".

now, since this trigger is fired often and the variable is thus changed alot, does that mean that since the variable IS different from every other variable that not destroying and nulling it is ok? now there are exceptions, right?

Wrong. When triggers fire often it is most important to destroy and null. Or else there will be memory and/or index leaks every time it fires and since the trigger fires a lot, there will be a lot of leaks.
Here is an example of a leak free trigger:

• Leak free trigger
  • Events
    • Unit - A unit Dies
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Footman
  • Actions
    • Set temp_point = (Position of (Triggering unit))
    • Set temp_group = (Units within 512.00 of temp_point)
    • Unit Group - Pick every unit in (Units in (Playable map area)) and do (Actions)
      • Loop - Actions
        • Unit - Kill (Picked unit)
    • Custom script: call RemoveLocation(udg_temp_point)
    • Custom script: call DestroyGroup(udg_temp_group)

Without the last two lines, it would leak.
As I said, to fully understand why you do not need to null global variables, you need to understand what exactly handles are, but you do not have to do it, to make leak free triggers. You just have to remember to destroy/remove handles you are not going to use anymore and if they are local, you need to null them.

 

[Herman]

@ Sankaku

I highly suggest learning JASS, GUI is very difficult when it comes to understanding handles + leaks

 

[SanKakU]

Well, i have learned a little JASS.

I've read the tutorials about JASS but out of everything what helps me the most is maps with systems that I can edit to suit my needs while I learn some JASS at the same time...

I can continue with this sort of thing and I think it helps, can anyone recommend some maps that do this sort of thing?

For example, In the tutorial about Item Pools, there is the map with Neutral Hostile units, when they die they drop items. Well, I used JASS with that trigger and I changed it from Neutral Hostile to specific units that are killed in a specific way. What I did for that was to create the events and conditions in the GUI and converted it to JASS. Then I took the actions and edited them, and put them in the converted trigger, and so on.

This is one sort of way I have learned JASS. But at this point, I'm just using other people's material. I know that good JASS users can make up their own material right? I have not progressed that far yet. If I keep using others' material, I will learn enough to probably make up some stuff on my own, I guess. But the challenge is finding simple enough systems that I can learn from, I suppose.

EDIT: ok, so i went ahead and checked out that kodo tag extreme 4.1 map, and it didn't crash, so i guessed that the triggers it uses would have actions that i need to put in my map to prevent memory leak. and guess what? looking at that worked! when spiwn said that you don't need to null the global variables, he's probably right, but, what it seems like he failed to mention is how to remove them(technically he did say how to remove them, but he used those custom text actions). i thought i was supposed to use custom text, but when i used the gui actions that were in the kodo tag map in place of the custom text actions that i had...my map stopped crashing. on a side note...with these special actions you cannot open such a map with the standard world editor. it will display alot of errors and then finally crash.
check it out:

• Actions
  • Do Multiple ActionsFor each (Integer A) from 1 to 10, do (Actions)
    • Loop - Actions
      • If (((Player((Integer A))) controller) Equal to (==) Computer) then do (Set TempGroup = (Units owned by (Player((Integer A))))) else do (Do nothing)
      • If (SaveUsActive Equal to (==) 0) then do (Set TempLoc = (Random point in (Playable map area))) else do (Set TempLoc = (Center of Jail <gen>))
      • If (((Player((Integer A))) controller) Equal to (==) Computer) then do (Unit Group - Order TempGroup to Move To TempLoc) else do (Do nothing)
      • Unit Group - Remove all units from TempGroup
      • Point - Remove TempLoc

well anyway it doesn't show that ? for point(and etc. but you get the idea), it shows a blue box which if i remember correctly i haven't seen before in the editor, or else i just haven't seen it often. check out the kodo tag map or mine for yourself if you want to see it.

edit: i have now figured out that lately all my crashing was from me making bad spell triggers. i'm not sure if some of the crashing is from custom text removing locations/unit groups or not but maybe not.

 

[RoboHippo]

Quick Tip!

You can save yourself some trigger work with dummies by setting their health regeneration to a negative value.

The easiest way is to set their health to the number of seconds that they'll need to exist for, and setting the regeneration to -1.

For 2 seconds; Health = 2, Regen = -1
For 1 second: Health = 1, Regen = -1
For 1 1/2 seconds: Health = 3, Regen = -2
For 1/2 second: Health = 1, Regen = -2
For 1/4 second: Health = 1, Regen = -4

Notice that each of these is actually a fraction, so life span in seconds = Health/(-1)Regen (provided that regen is negative). Simply convert the desired life span into an improper fraction, and there you go.

 

[SanKakU]

hey RoboHippo, that's a good idea, except that i don't know how to set negative health regeneration. even with phoenix, which has -25, you cannot edit the value to be anything less than 0. how do you work around that?

 

[RoboHippo]

It's actually quite easy, once you know how. In WE, just go to File > Preferences, and in the General tab check the box that says "Allow negative real values in the object editor". This will stay in effect until you turn it off. Remember, though, that you can murder your computer through misuse of negatives. But as long as it's logical, it should be fine.

 

[SanKakU]

oh great! because i was wondering how the hell to adjust my phoenix spell in that fashion!

 

[Razorbrain]

would that make them affected by life regeneration auras?

 

[RoboHippo]

unless you made them mechanical

 

[Just_Spectating]

just give them spell immune ability along with locust

 

[SanKakU]

spell immune isn't aura immune.

 

[Herman]

WWWWWWWWWWHHHHHHHHHAAAAAAATTTTTT?!??!?!?!?!?!?!!?!?!?!?!?

 

[SanKakU]

the discussion from this page carried over from the previous page, let me sum it up...
uhm...i think robohippo was talking about an alternative to triggering a dummy unit dying.
you can edit it so that the dummy unit has a negative regen factor and make him mechanical, the mechanical part being mentioned after someone asked about what if the dummy unit gets healed like by unholy aura? and of course just now, Just_Spectating here suggested that you make him immune to magic instead of mechanical, and i said that unholy aura would still affect the magic immune unit.

at any rate, ppl usually make their dummies invulnerable and if that's the case then they don't need magic immunity for anything...isn't that right?

been awhile since i worked on dummies and i only have one dummy spell to show for it.

 

[darkrider]

isnt there an option in gameplay constants that says something about immune units bestowing auras?

 

[Super-Sheep]

isnt there an option in gameplay constants that says something about immune units bestowing auras?

Yes.

 

[Herman]

Thanks for the reply, but I was sort of just kidding. To me it doesn't make much sense that a magic immune unit is affected by an aura.

 

[darkrider]

why?

i have a couple of magic immune units that i want them to BE affected by friendly auras but not by enemy spells

 

[Super-Sheep]

Example dh uses anti-magic potion and then doesnt gain attack speed aura. Makes sense.

 

[darkrider]

well... but perhaps you want spell immune units to be affected by some auras. Thats just what i said

 

[SanKakU]

the thing of it is that auras are not spells...there's no magic involved.
true there is a magic spell in ff8 called aura, but that's a spell that boosts the aura of the character much like a spell might heal a character or boost his attack power, etcetera...in warcraft 3 heroes are so powerful that they have these auras that affect their troops...there pretty much isn't anything magical about it.

let's look at some examples...dreadlord...
ok, as crazy as it sounds...units that are working with the dreadlord actually eat the enemies that they attack. well he is a demon after all...so apparently he influences them to do that. there isn't really anything magical about eating something, even if it is extremely gross. i guess the dreadlord himself takes some nasty hits and eats some bits of enemies and his allies see that and so they are encouraged to do the same.

ok what else? priestess of the moon...
she learns to shoot with even more accuracy and her form and skill and whatever impresses other allies so much that they can't help but work especially hard to improve their aim, seeing as how fantastic the potm is, they try their best to make their shots hit dead center, so their attacks result in more damage.

tauren chieftain...
as he gets more powerful from being more used to battling he is able to move around the battlefield quickly without harming himself by throwing his weight around too fast...allies who are with him in battle can't help but be encouraged by the protection that the mass of the tauren chieftain offers to be much quicker, confident that they won't inadvertently fly into an enemy's sword or arrow by running around too fast or swinging their blades around alot at nothing or shooting their ranged weapons too frequently.

anyway these are just a few examples, but you get the idea.

just as a reminder about the dreadlord...in the single player campaign he's not even a part of the scourge, just watches over the lich king to make sure he employs the scourge properly, at one point one of the dreadlords assists the lich king in obtaining his champion...but that was really an isolated event in which the dreadlord led undead into battle. and even then it was kindof just the dreadlord turning the humans into zombies...and considering that the other humans thought of Arthas as just killing other humans, they probably didn't transform so much as fall asleep and then become mind controlled. so i'm a bit skeptical as to how similar this was to the magic that the lich king used. although obviously the lich king's powers did come from the demons since they formed him, it is more probable that a number of demons gave him portions of their power...at any rate the demons who did give their powers to the lich king in order to create the swarm afterward had minimal undead powers. obviously they had some when they influenced the orcs to make death knights way back when. well, at any rate, what i'm trying to get at is that the fact that the dreadlord is actually an undead commander is a bit far-fetched and he isn't really an average undead commander on any level.

so it should actually be rare that you would have a dreadlord ally, especially considering that quite a few were killing by Arthas and Sylvannus. for gameplay purposes, you're kindof allowed to make whatever heroes you want and ally with whoever you want in multiplayer, so it's kinda weird and gross having a dreadlord ally making your druids of the claw eat the enemies that they attack, or same goes for your paladin or mountain king, and so on... but that's the way it is.

as for the events of the frozen throne and the dreadlords sicking undead on arthas, all the rules about the lich king's power kindof flew out the window when illidan struck the frozen throne from his watery hideout.

 

[RoboHippo]

That was quite the slightly off-topic essay, there.

I'm pretty sure that friendlies can cast spells on spell immune units, as friendly units appear to be able to heal Spell Breakers.
( ) But, if the unit has locust, then that shouldn't be a problem, unless positive AoE's affect them.

By the way:

This long discussion about dummies is not off-topic. Dummies are extremely effective ways of removing leaks. And since that's what the thread is about, we have not dereailed this thread, nor did we intend to.

 

[SanKakU]

i would have to check but i think the abilities themselves say whether or not they can target imagic immune and other things like mechanical, which is where the suggestion of a mechanical dummy came from i would imagine...and so heal and healing light can target magic immune but inner fire can't. and inner fire can affect mechanical but heal and healing light can't.

so anyway you could make auras not target mechanical if you wanted.

 

[Mechanical Man]

Why some leaks some not?

Why does those specific data types leak, while other not? Is that blizzard thought that some of the shouldn't and for some is better to make them leak? Or just they forgot?

 

[spiwn]

Personal opinion:
They intentionally didn't take care of that. This way they reduced their workload.
If they make a perfect game, no one will buy their newer stuff.

 

[Eleandor]

All composite data types potentially leak, simply because that's the way composite datatypes work on computers... Blizzard is not to blame for that.

Obviously, for the core game aspects blizzard has written leakless code the same way we need to write leakless code: by manually de-allocating the data. Imagine if you'd get a location leak every time a unit is ordered an order targeting a point...
For example: units are automatically removed from the game (and thus don't leak) when they stop decaying, which is on default 2 minutes after they die. It's only because you KNOW units are no longer used when they have decayed, that you can remove them and they don't leak.

Whenever we need to trigger something, the same rules apply to deleaking your triggers. The only exception is that, since units are automatically deallocated 2 minutes after their death, you no longer need to do it IF you kill a unit. It's pretty easy to detect when a unit can safely be deallocated so they don't leak, because all you have to do is check if they're still decaying or not. When they're no longer decaying, they're removed.

At the contrary, blizzard can't predict when they have to clean up a location (GUI: point) in one of your triggers simply because they don't KNOW if you're still going to use the location or not. With units they KNOW the unit will no longer be used because it decayed and cannot be resurrected or raised anymore, and thus they automatically remove it.

The only way they could automatically clean up any leak is through a sofisticated garbage collector which essentially is a sub-program that's running and constantly checks for objects that are no longer used. The main disadvantage of garbage collectors is that they're slow and inefficient. Following murphy's law, they always start running and checking for leaks at a bad moment: e.g. when a large battle is going on and you need all your CPU power to run the actual game and not the garbage collector. One of the core requirements of a game is that it runs as efficiently as possible because it demands a lot of resources from your computer, hence why no videogame uses automatic garbage collection. It's also the reason why the "only" games available for java are "simple" games.

The only thing we can blame blizzard for is that they "forgot" to include some deconstructors in jass, such as events and trackables.

 

[Justify]

Why is a garbage collector that slow? If there was an event "variable is assigned to xyz" and you could get the local in this special event, you could write your own garbage collector in 2 minutes (counting all variables on it, if it's 0 destroy it in most cases... you should care about stuff on the map an running timers, but thats nearly all)

 

[Eleandor]

I have no idea what you just wrote, and I don't see how that would collect garbage...

Anyway, here's how garbage collectors work:

Each application has a managed heap, which contains all objects that have been allocated so far. It also has a set of roots, which contains pointers that refer to objects on the heap or refer to null. In addition to this, roots also contain all local variables and parameters of a thread.

A garbage collector has the following algorithm:
1) Initialization: assume all objects in the managed heap are garbage
2) Pick the next root in the rootset.
3) Build a graph of all objects reachable through pointers in the current root. E.g. the garbage collector might find a global variable that points to an object in the heap. If the object was already added to the graph you stop your iterative search (to avoid circular infinite loops)
4) Pick a new root, and repeat 2 until all roots have been checked
5) Now, a graph containing all reachable objects has been generated.
6) Run through the object heap and any object that wasn't found in the graph that was just generated is found unreachable. It can thus be deallocated.

On a map with hundreds of units and thousands of destructibles, your garbage collector would have a lot of work... And then we're ignoring all the thousands of variables internally generated not visible to the gamer.