Avoid Memories leak

[initialD]

take your time..

[Aero]

It's not very practical for an actual game but I think it could work.

Might get it done tonight if I'm feeling ok after the 9 hour drive back today X.X.

[initialD]

Forgot about the string detector.
I got a few questions.
1. Do you think this kind of strings(or+ and) eat up a lot of memories?

Code: Select all

elseif cp_p3=="-abc" or cp_p3=="-xfe"
then call cde()
elseif cp_p3=="-int" and (s7!="-int") then
call SetHeroInt(u7,z7,true)
elseif cp_p3=="-agi" and (s7!="-agi") then
call SetHeroAgi(u7,z7,true)
elseif cp_p3=="-str" and (s7!="-str") then
call SetHeroStr(u7,z7,true)

2. What's diferent between BJ and non-BJ?
Example: SetPlayerStateBJ and SetPlayerState, both of them work. what's different?

3. I saw someone set string s back to null in the end of a function, some set s="", or like in your cheat pack, you didn't even care to set it back to either null or "".
Which ones are better? Would you mind explain a bit. Thanks

[JJ2197]

Well if you want a more optimized script you want to use non-BJ (you'll notice optimizers have
and anti-BJ option)

As for the nulling you use "" to null a string and null to null pretty much everything but numbers.

I would imagine he didn't do it, because maybe he didn't care?

[Aero]

First, strings cannot be 'nulled'.
Secondly, strings don't leak (They are hardcoded non-wc3) so they DO NOT need to be set to "" or 'nulled'.

Third...inside the war3.mpq/war3x.mpq/war3Patch.mpq are 3 .j files (Only 2 of them we really care about).

common.j
Blizzard.j

common.j contains all your variable types as well as all the native functions.

Blizzard.j contains functions that are made up of native functions.
A lot of GUI use Blizzard.j functions as wrappers for native functions...probably to improve understandability and readability.

The Blizzard.j functions usually have the term 'BJ' (B.j) in them to indicate that they are Blizzard.j functions but not all Blizzard.j functions have 'BJ' in them.

So basically, when you see a function that has 'BJ' in it or is complex (like SetUnitFacingToFaceLocTimed) it's almost 100% likely to be a Blizzard.j function. Also, a lot of functions that take a location or point as an argument are BJs (As JASS is mostly x and y; there are quite a few exceptions like CreateUnitAtLoc).

The advantage of using natives is that they are MUCH FASTER!

[initialD]

Code: Select all

function GetForceOfPlayer takes player whichPlayer returns force
    local force f = CreateForce()
    call ForceAddPlayer(f, whichPlayer)
    return f
endfunction

This function leaks as a force (A handle) is not cleaned up.

.

A new question for you Aero.
The force leaking problem>>> could I just set force to NULL to clean it up?
If can't. What's the correct way to clean up the local force to avoid memory leaks?

[Aero]

No, setting the force to null will clean the memory used by the local variable that the force is stored in.
However, the handle will still exist and will leak.

The following must occur: call DestroyForce(<force>)

A way around this is to use the pre-existing player forces...
bj_FORCE_PLAYER[index] (0-11 if I'm not mistaken...might be 1-12 but I doubt)

Or just destroy the force after use...

[initialD]

I think I will just destroy the force because I don't really like BJs. They will eat up more spaces if I am not mistaken.
thanks.

[Aero]

You might as well use "bj_FORCE_PLAYER[index]" anyways.
The forces are already declared into memory.

[initialD]

Since unused integer would not be nulled. May I ask what is the best way to nullify them?

I have figured out a bit.

1)use a function?

function XXX takes interger Z returns nothing
endfunction

2)manually return?
set integer=0
if integer=0 then
return

3)call a native function?
set integer=0
call Player(integer)

which is betteR? what is your method, Aero?