a small tidbit about PlaceAtMe(), casting, and Save file bloat

[GenioMaestro]

6 minutes ago, Roggvir said:

Yeah, i made a mistake when testing it (used single update registration while i thought i used the periodical one and it expired too soon), so yes, registering for OnUpdate does prevent the game from deleting the object.

Sorry about that - hope i fixed it in all the quotes.

Well, we advance one step. Thanks.

 

But that is not the only error or wrong concept in yours explanations.

You have much more erroneous concepts and i beg you to read again my messages to try find yours bad concepts and yours own errors.

[Roggvir]

2 minutes ago, GenioMaestro said:

Well, we advance one step. Thanks.

Actually, we advance few more, because i found a flaw in one of my other testing methods - you were right, the script wont get deleted while it has a thread running.

So i'll fix those comments...

[GenioMaestro]

4 minutes ago, Roggvir said:

Actually, we advance few more, because i found a flaw in one of my other testing methods - you were right, the script wont get deleted while it has a thread running.

So i'll fix those comments...

WOW... we advance a BIG step. Thanks.

 

Continue reading, please.  Maybe you can discover more things and finally understand how really works the Script Engine and the Game Engine.

[Roggvir]

4 minutes ago, GenioMaestro said:

Continue reading, please.  Maybe you can discover more things and finally understand how really works the Script Engine and the Game Engine.

Nope, thats all i was able to find.

The reason for the object not getting deleted in that example is still just becaue a reference to the object exists.

And in your example, varA is a reference to script instance and varB and C are still references to the objectReference.

[Roggvir]

Anyway, that was a fruitfull discussion, keep it going if you still have the energy, maybe i can learn some more.

[Myst42]

2 hours ago, GenioMaestro said:

No, really, the game does not lie because the main problem here is the context.

Papyrus always runs the script in a context

Details, details... call it what you like but on practice, the game is still "lying"

Ok, Ok... "context change" whatever, we're not getting the true ID of the referenced thing. I get that it can be useful for game mechanics as we can do stuff to the object as long as we're in game context, but it still poses a threat we weren't previously aware of.

2 hours ago, GenioMaestro said:

And really the script executes FF00085c.Delete () regardless of whether you put self in front of the delete or don't put it. Because self, in this context, becomes FF00085c and even if you don't put self, really, the compiler is putting it for you, because all the direct actions of the script are redirected to the object that supports the script, depending on the context in which run.

Ok, so you really can use Delete() and Disable() because in "context" it will point to the object, BUT... you didn't answer the other part of the question which was wether we can actually delete that or not, because script A is still storing a reference to the spawned object attached to script B.

2 hours ago, Roggvir said:

Then it got a bit derailed into blaming circular references, which is not only NOT happening in the example case, but is also irelevevant to the problem with live references and Delete() - the game only cares whether and object is referenced, it doesn't care where is it referenced, and whether any reference is circular or not, makes no difference.

I've seen a couple of these discussions, and often, they tend to get "derailed" into detail discussion and quickly evolve into shitflinging, but... I think there's a valid point here because you spotted a potential hazard in scripting, and we should have clarity on exacly, what went wrong, so that people knows what not to do.

Genio calls it a "circular reference", you don't seem to like that notion or concept, but in the end, something, is being referenced, and we should know how.

Which brings me back to my question. Is it an immortal entity because it is being referenced, wether as a script or an object reference, or this just happens to script instances?

If it's because it's a reference, I figure my example from the previous post should also give problems since script A, as long as it's active, keeps referencing an object that just deleted itself (or tried to).

1 hour ago, Roggvir said:

20 hours ago, GenioMaestro said:

If the object has an associated script that is running, that object cannot be deleted. But it is not necessary for the script to be actively running in the Active Scripts zone to prohibit the deletion.

No.

Whether an object has an associated script, running or not, never prevents the game from deleting the object (and the script with it).

So Genio's thesis is that Object -> Contains associated script; Script is running -> prevents deletion

Then Roggvir says Object -> Contains associated script; script is running -> object can be deleted no matter what

But regarding why we can't remove this particular thing

Genio says: Script is immortal because it's referenced by itself (circular) ; And both seem to agree on this because being referenced by something prevents a thing from being deleted.

Then Roggvir says Object is immortal because it's being referenced by its script.

 

I guess the only way to settle this is to make a test, spawn an object attached to an ObjectReference script that contains a loop function that will keep it running indefintely, then make something to Delete() the object. If the object is sucessfully deleted with its running script, we prove that objects can be deleted regardless of their active scripts. If not, then the reason is different.

A similar test could be made to see if being referenced is also an equal problem. Fastest example I can imagine is my example test from the previous post. If the object being referenced by script A can be removed, it's not related to references. If it can't then being referenced matters.

 

If both tests were to come back positive, then this "circular" deal would be a double danger since it's caught up on both ends, an active script and a pointing reference.

 

EDIT: Oh... while I wrote, didn't notice some concesions were made. Nice to see things getting civilized again.

1 hour ago, Roggvir said:

It is enough that the script is waiting for an update with OnUpdate because that causes the script to register to receive a message and prohibits the removal of that instance of that script.

I'm not sure what you mean by that, but I think I've seen cases of stuff getting removed before its script update gets executed.

Specifically... magic effects. If the magic effect has an OnUpdate maintenance loop, it will work for as long as the effect is active BUT... the instant the effect ends, there is already a queued update and when it comes, it can give an error on the log saying something about the script instance not being attached to anything and being unable to execute OnUpdate() iirc. It's a small, meaningless error usually because life goes on, and the effect ended just as fine, but it still throws that error.

It was a surprise for me to find out that, since it's one weird example of code ending before it's executed, but I guess it's how it should be, or else some things wouldn't work they way they're supposed to.

Then, if you mean it's "active" while it's waiting, for the update, I can confirm. When the update finally comes, if there's no form sustaining it, it will just give an error (and probably remove the script instance), but while it waits, it's running.

 

[GenioMaestro]

5 hours ago, Roggvir said:

Anyway, that was a fruitfull discussion, keep it going if you still have the energy, maybe i can learn some more.

You have to learn much more because you still have misconceptions.

 

5 hours ago, Roggvir said:

The reason for the object not getting deleted in that example is still just becaue a reference to the object exists.

And in your example, varA is a reference to script instance and varB and C are still references to the objectReference.

This paragraph is totally incorrect and shows that you are understanding the problem in the wrong way.

 

In my example and in YOUR code, we have no DIRECT reference to the underlying object.
You believe that the script refers to the object and therefore the object cannot be deleted.

That is totally wrong.
In other words, you think the script has a reference to the underlying object and that reference should be removed by setting miscItem = none to release that reference that is blocking the object.
That is totally wrong.

 

The fact that the game says that the value of self is FF00085c does not mean that self refers, in a direct and REAL way, to the object with that number.
Simply, the script is executed in the context of that object and any reference to "self" in that context is converted to FF00085c while the REAL value of "self", as confirmed by ReSaver, is 2323a3c3.

 

A DIRECT reference to the object that provides the execution context cannot be obtained. It is impossible.
The only way to obtain the FF00085c code is by using "self." It's the only way. The game has no other way of providing that value.

But "self", really, internally, is worth 2323a3c3 and when asked about "self" in that context you get FF00085c. But that is not its REAL value. That value is obtained because the context hides the real value and gives it the value FF00085c.

The screenshot from ReSaver demostrate it in a very clear way.

 

 

I continue to try clarifying things.

 

It is really very difficult to block an object when referencing it in a script.

The situation that you imagine you have is much more complex and it is very difficult to create it.
Myst42 tried to create it with that example but it was wrong to put the names of the variables.

 

I am going to use my example and I am going to modify Circular_Eff_Script because in the code lines of the Circular_Reference script it is impossible to obtain a DIRECT reference to the object. The only way to get their code is to use "self" but that give us ONLY the code and NOT give us a DIRECT reference to the object. Really give us a DIRECT reference to the script. We must use other script for have a DIRECT reference to the object.

 

If I modify, for example, Circular_Eff_Script and change it this way:

Scriptname Circular_Eff_Script extends activemagiceffect
Weapon Property Circular_Katana auto
ObjectReference Placed_Katana
Event OnEffectStart (akTarget Actor, akCaster Actor)
	Placed_Katana = Game.GetPlayer (). PlaceAtMe (Circular_Katana)
Endvent

I am really getting a DIRECT reference to the object in the variable Placed_Katana and I am really blocking the object and preventing its destruction. But only and exclusively while the spell exists.

Can this be a problem ???
It depends on the type of spell, how it is defined and how long it has.

I copied it from the base game using one of the light spells and I think it lasts 60 seconds. Therefore, for at least 60 seconds, that object will be locked because it is actively referenced in a DIRECT way in that script.
If the spell is cast again to generate another cataka, theoretically, another catana would be created that would also be blocked.
But if the spell has the NoReCast mark, the old spell disappears by releasing the variable and the object locked by that variable. Secondary, a new katana is created that will again be blocked for the duration of the spell.
But if the spell is of the hability type, it can only be casted once and the next time we launch it the game says that the actor already has the ability and simply does not cast the spell and a new katana is not generated. But the katana that is generated the first time the hability type spell is cast would be locked forever.

Really, the only way to store 50k katanas would be using a spell with a very long duration, like several million seconds, and using a special type of spell that can be recast and we can have that active spell 50k simultaneous times for a long time and, of course, putting it as hidden so that the player does not see 50k spells in active effects.

Another example would be using a quest, because the quest script is instantiated while the quest is active. But creating a single variable would not be valid because every time the quest function is called the code would be replaced and only one katana would be blocked. We should create an array to store all the codes of each one of the generated katanas and we would have a maximum of 128 katanas because it is the limit of the matrix in Papyrus. To store 50k katanas we would have to use PapyrusUtil or JContaines.

As you can see, it is not so easy to block an object using a DIRECT reference in a script because scripts usually have a very short lifetime. The only REAL way to do it is on purpose or by accident.

 

 

What Roggvir thinks happens is not what really happens.

 

You think the problem is that I have Legenday and you have Special. NO.
You think it may be because of the ReSaver version. NO.
You think that I am wrong and that you are right. NO.

 

I beg you to do specific tests using your own version of your Skyrim Special Edition and to record the game and see with your own eyes what value have the variables in your own savegame using your own version of ReSaver.

I always say the same. Tests, tests and more tests. Real data, screenshots that demonstrate the position of each one.
This is a discussion where it is easy to demonstrate and see what really happens. Just put a little interest, write a few lines of code and make a few test and a few screenshots.

[GenioMaestro]

8 hours ago, Myst42 said:

Details, details... call it what you like but on practice, the game is still "lying"

Ok, Ok... "context change" whatever, we're not getting the true ID of the referenced thing. I get that it can be useful for game mechanics as we can do stuff to the object as long as we're in game context, but it still poses a threat we weren't previously aware of.

Not, simply the game is hidding the REAL values because you not need that REAL values.

The computers works in that way. For example you not need know in what sector of the disk is stored a file.

 

What you need is that the game works in the intended way and that is made thanks to the context.

Following the example, you need that file was readed correctly no mater in what sector of the disk is stored.

 

But really, we not have any REAL danger in this post.

Simply, Roggvir is making a incorrect and unnecesary thing like put a line of code like:

miscItem = self as form

because, as i allready said, the value of "self" is always the same in all the lines of the script. But they say:

10 hours ago, Roggvir said:

It is totally neccessary in the real script, this was a simplified example.

And ussing all my knownledge in programing i can not undestand WHY they say that.

If Roggvir allow me see the complete code, maybe, i can know what are exactly making for need that.

 

 

Really, is very dificult make a save file bloat because the game is designed for not make it. 

The only way is make it intentionally or by accident writing erroneous or uncontroled code.

Because, really, the game, the mods and the Papyrus Engine, normally, works in the intended way.

 

The game and the Papyrus Engine have a predefined rules and we must follow it. I we go against the rules bad things go to happend. We only need follow the recomendations and alerts exposed in the web page of the Creation Kit and the 90% of the times that cover us against any error.

 

When we have a problem, the first site for request help is the web page of the Creation Kit. 

In the case exposed by Roggvir this is the page that must read:

https://www.creationkit.com/index.php?title=Persistence_(Papyrus)

That extend to that page:

https://github.com/xanderdunn/skaar/wiki/Understanding-Forms%2C-Object-References%2C-Reference-Aliases%2C-and-Persistence

And the code example have a line like:

myObjectReference = None

Simply, Roggvir not read the correct documentation and they create a problem inside their mod that cumulate scripts and objects in a infinite way. And the only solution to the problem, as the documentation say, is put the variable to none.

 

Roggvir has not discover any new problem because that web pages has date from 2014 but as they not read the correct documentation they make a post for alert to others developers about their error and how solve it.

 

The BIG problem is that Roggvir understand the problem in a incorrect way thinking that the object are locked by the script when the REAL problems is that the script is locked by their OWN variable that aim to the same script.

 

 

As i say, this is not a NEW problem, i know it from a lot of years ago. When i read the message from Roggvir i inmediatelly know what is happend and why and i try explain the problems in the best posible way.

 

You are alerted thinking that this can be a common problem but again that is not true.

The only way for have a problem is making the things in the bad way.

But sometimes we learn what is the good way after have a lot of problems.

That is normal because a lot of times we not know how make the things and must learn it.

 

Really, have a object or a script blocked is very difficult.

Not hapend normally and is caused by an error in the program.

 

Is fantastic that you want learn but the information exposed in this post only can help you to solve this problem. Others problems, normally, are caused by others motives and is very strange that can have any relation.

[Roggvir]

On 9/15/2019 at 6:43 PM, GenioMaestro said:

Simply, Roggvir not read the correct documentation and they create a problem inside their mod that cumulate scripts and objects in a infinite way. And the only solution to the problem, as the documentation say, is put the variable to none.

I think i did read it. That script is an example, used to remind people about the fact that when they cast something to a form, and store it into a variable of type form, it may result in the game creating a reference to the object.
 

On 9/15/2019 at 6:43 PM, GenioMaestro said:

Roggvir has not discover any new problem because that web pages has date from 2014 but as they not read the correct documentation they make a post for alert to others developers about their error and how solve it.

Of course it isn't a new problem. But please, show me the place where the documentation mentions that if you cast something to a form and store the result in a variable typed as form, the game will actually store it as a reference to the object you cast from.

 

On 9/15/2019 at 6:43 PM, GenioMaestro said:

The BIG problem is that Roggvir understand the problem in a incorrect way thinking that the object are locked by the script when the REAL problems is that the script is locked by their OWN variable that aim to the same script.

The script variable in my example, contains a reference to the object, not to the script.
So, there is no variable referencing the same script, but a variable referencing the object the script is attached to.
If there is a reference to an object, the game will refuse to destroy that object.
That reference could be on any script, even a script completely unrelated to this one, and the result would be the same - the game will refuse to destroy the object, because there is a reference pointing to it.

IF the variable would point to the script, the game would still refuse to destroy the object, because it couldn't destroy the script attached to it (which it couldn't destroy because of the reference pointing to that script), but that is not what is happening in that example - again, the variable references the object, not the script.

 

[Roggvir]

On 9/15/2019 at 6:43 PM, GenioMaestro said:

Simply, Roggvir is making a incorrect and unnecesary thing like put a line of code like:

miscItem = self as form

because, as i allready said, the value of "self" is always the same in all the lines of the script. But they say:

On 9/15/2019 at 2:10 PM, Roggvir said:

It is totally neccessary in the real script, this was a simplified example.

And ussing all my knownledge in programing i can not undestand WHY they say that.

If Roggvir allow me see the complete code, maybe, i can know what are exactly making for need that.

It is not incorrect, and it is not unnecesary.

btw. have you ever saw any of those typical "Hello world" examples? did you also wonder "hmmm, why would anybody do that?"
The line you seem so puzzled by, is originally from a different script and looks like "_form = _ref as form".

It is a long script full of stuff unrelated to the problem, so when posting an example, i decided to "compact" the relevant stuff from two scripts into one small example script.

[GenioMaestro]

1 hour ago, Roggvir said:

It is not incorrect, and it is not unnecesary.

btw. have you ever saw any of those typical "Hello world" examples? did you also wonder "hmmm, why would anybody do that?"
The line you seem so puzzled by, is originally from a different script and looks like "_form = _ref as form".

It is a long script full of stuff unrelated to the problem, so when posting an example, i decided to "compact" the relevant stuff from two scripts into one small example script.

Let me see the entire script, or the entire mod, if necesary, because i can not understand why you are so convinced of the necessity of store "self" inside a variable. From the OOP(Object Oriented Programing) ideology is totally unnecessary because, as i already said, the value of "self" is always the same in all the lines of the script, no matter if the script have 10, 100 or 1000 lines.

[GenioMaestro]

3 hours ago, Roggvir said:

... when they cast something to a form, and store it into a variable of type form, it may result in the game creating a reference to the object.

Seems that you continue thinking that the problem is caused by the cast and that is not true.

 

3 hours ago, Roggvir said:

... if you cast something to a form and store the result in a variable typed as form, the game will actually store it as a reference to the object you cast from.

Again, the cast is not the problem.

 

3 hours ago, Roggvir said:

The script variable in my example, contains a reference to the object, not to the script.
So, there is no variable referencing the same script, but a variable referencing the object the script is attached to.

NO... you continue having the same conceptual error.

If there is a reference to an object, the game will refuse to destroy that object.

CORRECT
That reference could be on any script, even a script completely unrelated to this one, and the result would be the same - the game will refuse to destroy the object, because there is a reference pointing to it.

CORRECT

IF the variable would point to the script, the game would still refuse to destroy the object, because it couldn't destroy the script attached to it (which it couldn't destroy because of the reference pointing to that script),

CORRECT

 

but that is not what is happening in that example - again, the variable references the object, not the script.

NO... your script and my script have a reference to the script.

How you explain the data showed in the screenshot from ReSaver?

Do you think that ReSaver is showing incorrect data? Go to say that to the creator of ReSaver.

Have you make specific test with your game?

Have you look, ussing ReSaver or SavegameCleaner, the data that your savegame store?

 

-----------

 

Seems that you main problem is that you think that when we cast

self as form

the Papyrus Engine change the memory pointer addres from the script to the underliying object.

 

Then, every time we make a cast like

self as Quest

we get a DIRECT reference to the quest, and when we make a cast like

self as ReferenceObject

we get a DIRECT reference to the object.

All that is totally false. Make test whit your game and look the stored data inside the savegame.

 

Make a cast never, absolutelly never, can change the value of the variable.

The only problem that we can have making a cast is when we use INCOMPATIBLE data types because we can lost data but normally we make a cast for change the things that we can make with the varible.

When we cast a float to an int we are making an incompatible cast, because the int data type can not store the decimals. But when we cast a float to a string we lost the matematical capacity of the variable but we gain the string capacity.

When we make a COMPATIBLE cast the value of the two variables are the same and one variable must act in the same way than the other variable.

If the cast are INCOMPATIBLE we can lost data or functionality because, for example, a string can not store a pointer.

 

 

If the script have a internal variable called "self" and we put "self" inside varA, "self" and varA must have the same data and, if their are pointers, must aim to the same memory address and one must act like the other.

If "self" is a pointer to the script varA must be a pointer to the script.

 

If we write "self as form" that not make that magically the pointer aim to the form.

If we write "self as quest" that not make that magically the pointer aim to the quest.

If we write "self as actor" that not make that magically the pointer aim to the actor.

Is imposible. Look the data in the screenshot for verify it. 

The value of the variable, and for extension, the memory address aimed by the pointer, MUST BE ALWAYS THE SAME.

 

Make a cast never change the value. Only change the data type used to store the variable and allow us call functions that are alowed only to that data type.

If we write "varA = self as string" we can ask "If varA.Length() = 10"

If we write "varA = self as quest" we can ask "If varA.GetStage() = 10"

Is the only motive for make a cast. Have access to the functions allowed only by that data type. But that NEVER can change the value of the variable or the address aimed by the pointer.

The value of the variable, and for extension, the memory address aimed by the pointer, MUST BE ALWAYS THE SAME.

 

 

Another point that seems you not understand is the contex. I write a lot and i beg you read my post again and search some tecnical information about what is the contex in Papyrus and how the Papyrus Engine manage it because diferent context give diferent values to self.

 

 

I not know another way for explain this because the exact problem is:

3 hours ago, Roggvir said:

IF the variable would point to the script, the game would still refuse to destroy the object, because it couldn't destroy the script attached to it (which it couldn't destroy because of the reference pointing to that script)

Exactly, the object can not be destroyed because have one script atached to it that can not be destroyed because have one variable aiming to "self" and that is a circular reference.

[Roggvir]

On 9/19/2019 at 8:53 PM, GenioMaestro said:

The script variable in my example, contains a reference to the object, not to the script.
So, there is no variable referencing the same script, but a variable referencing the object the script is attached to.

NO... you continue having the same conceptual error.

Sorry, but ReSaver clearly shows that the variable is referencing the OBJECT, not the script instance.
How is that my "conceptual error"?
I am seriously starting to think you are just trolling me, so i give you one chance to explain what you mean, and if that wont make sense again, i will stop indulging you.

 

On 9/19/2019 at 8:01 PM, GenioMaestro said:

Let me see the entire script, or the entire mod, if necesary, because i can not understand why you are so convinced of the necessity of store "self" inside a variable. From the OOP(Object Oriented Programing) ideology is totally unnecessary because, as i already said, the value of "self" is always the same in all the lines of the script, no matter if the script have 10, 100 or 1000 lines.

Did you even tried to read what i wrote?
I guess not, because then you would know that in the original script it isn't storing "self", but "_form = _ref as form" where "_ref" is the object reference.
I only compacted it into one script where i used "self" because it is convenient and the result (as far as example goes) is the same.

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

Seems that you continue thinking that the problem is caused by the cast and that is not true.
...
Again, the cast is not the problem.

What the fuck? Where do i say the cast is the problem?
I just describe what happens when you do that cast, what is the result of that cast.
How did you get the idea that i am saying the cast is the problem from that??? I even keep repeating that the problem is the resulting reference stored in that variable!

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

but that is not what is happening in that example - again, the variable references the object, not the script.

NO... your script and my script have a reference to the script.

Nope. I already told you several times, and it still didn;t change, the variable in my script still holds a reference to the object, not to the script instance of the script attached to that object.
It doesn't matter how many times you say it isn't so - that wont change the reality, so stop with this bullshit already.

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

How you explain the data showed in the screenshot from ReSaver?

Do you think that ReSaver is showing incorrect data? Go to say that to the creator of ReSaver.

Have you make specific test with your game?

Have you look, ussing ReSaver or SavegameCleaner, the data that your savegame store?

YES! EXACTLY! I already told you this!
The version of ReSaver you are using, does not show all details, or you are showing data that isn't result of my example script.
I do not need to go tell that to the creator of ReSaver, because he obviously knows it, because the version i am using does show the difference.

I see a difference between object reference and script instance of a script attached to that object reference.
How many times do i have to repeat this?

 

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

Seems that you main problem is that you think that when we cast

self as form

the Papyrus Engine change the memory pointer addres from the script to the underliying object.

 

Then, every time we make a cast like

self as Quest

we get a DIRECT reference to the quest, and when we make a cast like

self as ReferenceObject

we get a DIRECT reference to the object.

All that is totally false. Make test whit your game and look the stored data inside the savegame.

Well, i dont think it is CHANGING any pointer addresses, that makes no sense, but otherwise yes, in MY EXAMPLE, the assignment of the result of "self as form" into variable "miscItem" of type form does result in the game creating a reference to the OBJECT.
As i keep repeating over and over - that is what i see in ReSaver!

So, unless the ReSaver is making things up, the variable is referencing he object.
I dont know about that quest, but i take your word for it, since i didn't test it (then again, if you tested it the same way you tested my example, maybe you shouldn't take the results too seriously).
So again, if you use my example and look at the data (but not with your retarded version of ReSaver which doesn't show all details), you will see that the variable is a reference to the object.

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

If the script have a internal variable called "self" and we put "self" inside varA, "self" and varA must have the same data and, if their are pointers, must aim to the same memory address and one must act like the other.

If "self" is a pointer to the script varA must be a pointer to the script.

Wrong ASSUMPTION, and out of context.

As i already wrote before, it depends on how the cast between the two types is implemented.
Again, the data i see in ReSaver say that the variable IN MY EXAMPLE holds a reference to the OBJECT, not to the script instance.

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

If we write "self as form" that not make that magically the pointer aim to the form.

If we write "self as quest" that not make that magically the pointer aim to the quest.

If we write "self as actor" that not make that magically the pointer aim to the actor.

Is imposible. Look the data in the screenshot for verify it. 

The value of the variable, and for extension, the memory address aimed by the pointer, MUST BE ALWAYS THE SAME.

Well, no. I repeat again - it depends on the implementation of the cast between the two types.
Again - to me, ReSaver shows that the variable IN MY EXAMPLE holds a reference to the OBJECT, not to the script instance.

 

 

On 9/19/2019 at 8:53 PM, GenioMaestro said:

I not know another way for explain this because the exact problem is:

On 9/19/2019 at 6:08 PM, Roggvir said:

IF the variable would point to the script, the game would still refuse to destroy the object, because it couldn't destroy the script attached to it (which it couldn't destroy because of the reference pointing to that script)

Exactly, the object can not be destroyed because have one script atached to it that can not be destroyed because have one variable aiming to "self" and that is a circular reference.

Except in MY EXAMPLE, the variable holds reference to the OBJECT, not to the script instance.
And again, i repeat - even IF the variable would point to the script, resulting in what we humans call "circular reference", the problem is not a "circular reference" but simply a reference.
Again - the game doesn't give a crap about how you call what, it only cares about whether there is a reference to the object or any of its attached scripts no matter where that reference is!
So, whether we call the reference "circular" or not, has nothing to do with the problem.
The problem is not about "a circular reference", but about "a reference" which can be circular (but is not in my example).