Script:Start not called on entity:Copy

[Lunarovich]

I've run into a situation which seems to be counterintuitive. When I run the following code

 

local entity = self.entity:Copy()

 

end try to access entity's properties that get set in Script:Start() directly afterwards and via entity.script.prop, they are all nil, that is, they don't exist at all.

 

What is more, Script:Start() does not get called at all, even after the tick/frame in question and before the Script:Update() of the next tick/frame.

 

On the contrary, if I run the same code with a line added

 

local entity = self.entity:Copy()
entity.script.Start(entity.script) -- here I call manually Script:Start() of the entity

 

everything works as expected. So, shouldn't this behavior be built into LE? I mean, everyone expects that an initialization script runs on entity creation (instancing / copying).

[nick.ace]

So, shouldn't this behavior be built into LE? I mean, everyone expects that an initialization script runs on entity creation (instancing / copying).

 

I don't know about that. The behavior could be trying to emulate forking (basically copying while retaining state), which is also a type of copying.

 

However, from a few tests, neither seem to be an intuitive behavior:

• Looped functions (such as UpdateWorld() and UpdatePhysics()) are where the calls start from (so yeah Start() is skipped)
  
• Variables reinitialize (so the copy acts like a fresh entity)
  

 

These behaviors should be defined better in the documentation or one of the paradigms should be chosen imo.

[Lunarovich]

Thanks for the answer!

 

The behavior could be trying to emulate forking (basically copying while retaining state), which is also a type of copying.

 

If the part of the current state of the entity depends on the Script:Start(), that part will never be copied to the new entity, since Script:Start() never gets called and copy does not simply make an exact replica of the instance.

 

Looped functions (such as UpdateWorld() and UpdatePhysics()) are where the calls start from (so yeah Start() is skipped)

 

Agree. However, that happens only in the next application tick. In the current application tick - the one that we copy the entity in -, the script is attached and available (it is not nil). What I find misleading is the fact that a copied entity gets the script without a normal flow of script execution.

 

As a sidenote, there are some other script quirks, at least IMO. For example, one cannot call multiple times Window:MouseHit() inside the same Script:Update() function invocation and expect to get the same results. The first time, call to WIndow:MouseHit() gives a reliable value. Every subsequent time it gives nil, so you cannot make two susequent tests with Window:MouseHit(). Instead, you have to register a value in the variable.

[Thirsty Panther]

 

As a sidenote, there are some other script quirks, at least IMO. For example, one cannot call multiple times Window:MouseHit() inside the same Script:Update() function invocation and expect to get the same results. The first time, call to WIndow:MouseHit() gives a reliable value. Every subsequent time it gives nil, so you cannot make two susequent tests with Window:MouseHit(). Instead, you have to register a value in the variable.

 

This thread may be of some help.

 

http://www.leadwerks.com/werkspace/topic/11709-mousekeyboard-states-in-multiple-scripts/

[Lunarovich]

Thank you. I find it quite disconcerting, as a matter of fact, that you have to use some long and eventually bug prone and complicated code to be able to read simple input event several times in one frame. (BTW, not a single word in API reference about it). It goes against the intuition and philosophy of LE, which I sum up as a meaningful and up to the point simplicity. I have chosen it exactly in order not to have to do such things.