Small question about memory leaks removing

[Parsival]

Hi.

If I set TempPoint like this:

• Actions
  • Set TempPoint = (Center of Region)
  • Set TempPoint = (Center of OtherRegion)
  • Custom script: call RemoveLocation (udg_TempPoint)

Does (Center of Region) still stay in memory?
I mean, do I have to remove location before setting new value?

Thanks.

 

[KaerfNomekop]

Yes, yes it does.

 

[Squeekems]

I do not think that you need to remove the location before setting a new value within the trigger. You only need to remove the location when you are done with it in the trigger.

That is what I have been told anyways. <( >.>)>

 

[Accname]

You only need to remove the variable objects before you set the variable to a new object.

That is the whole idea of a memory leak.

This:

Set TempPoint = (Center of OtherRegion)

Is not a leak.
Thats just the normal usage of memory for certain tasks.

This however:

Set TempPoint = (Center of Region)
Set TempPoint = (Center of OtherRegion)

Is in fact a memory leak.

Why? Because we create 2 objects but we use only one variable. We can only point towards one of the locations and we can only work with that one.
The other location does still exist. Its there, somewhere, in your RAM. But you cant use it anymore because it doesnt have a name!
Things without a name cannot be used, they are a memory leak.

That is why you have to remove the objects behind the variables before you set the variable to an other object.
If you are never going to set it to an other object you never need to remove it.

 

[Iky]

i have a question, if be this:

Set TempPoint = (Center of Region)
Custom script: call RemoveLocation (udg_TempPoint)
Set TempPoint = (Center of OtherRegion)
Custom script: call RemoveLocation (udg_TempPoint)

 

[Squeekems]

I learned that variables point to a specific location in memory. You change what is in that location at any time and it is only changing that part of the memory. It does not just create some random nameless variable when doing that. That is how I learned variables worked. But hey, if the world editor compiler is retarded, so be it, lol. I do not see the benefits of having the game create a completely new nameless variable when re-assigning a variable.

 

[Accname]

i have a question, if be this:

Set TempPoint = (Center of Region)
Custom script: call RemoveLocation (udg_TempPoint)
Set TempPoint = (Center of OtherRegion)
Custom script: call RemoveLocation (udg_TempPoint)

This does not leak.

@Squeekems:
A variable is a pointer to a certain object.
A location is an object.
Code which looks like this:

Set TempPoint = (Center of Region)

Does the following.

It creates a new Location-Type object and saves it and it sets the pointer of your variable to this object.
If you write down this code:

Set TempPoint = (Center of Region)
Set TempPoint = (Center of Region)
Set TempPoint = (Center of Region)

It creates a location-object, sets the pointer, creates another location-object, sets the pointer
and creates another location-object and sets the pointer.
You will end up with 3 objects but still only a single pointer which points to the last created object.
The other 2 will be unaccessible for you for now on because there is no pointer pointing to them.
They are thus called leaks.

The editor isnt stupid, thats how things work in many scripting languages, C++ for example.
There are certain languages like Java or many Interpreter-Languages which have an automatic garbage collection which handles all kinds of memory leaks by itself.
However, these languages are usually slower and have worse performance.

If you want your game to run smooth even if many things are going on at the same time you have to invest a little bit of work into your scripts, like handeling the garbage collection manually by yourself.
We are not living in candy-land.

 

[GFreak45]

dont you think the native set variable function should have an automatic set variable = null/0 before it actually sets the variable?

 

[Iky]

some programming languagens do this automatic variable/object clear

 

[Parsival]

Oh, thanks for the answers. I haven't expected it will cause such a discussion. Accname is right IMO. I thought the same and that is why i created this topic.

 

[Squeekems]

Yeah, Accname is right, lol. See, I did not know the variables in this languages just act like pointers. I can not see any benefit for doing it this way, but if that is what we are given to work with...