Owner Change

[Wandering Soulstar]

Hi All,

Question regarding a script detecting owner change. Now I understand clearly from the Wiki that I can use the changed event with the CHANGED_OWNER flag to check this, but I have a specific scenario in mind:

• I own the script and the prim it is in.
• I Set the script to not running
• I then give the prim and script to another
• They then start the script running

 

?? Will the changed event then fire ??

 

Thanks in advance!

Wanda

 

[Nova Convair]

In theory: yes
Did I ever test that? no

 

[Qie Niangao]

Apparently not.

I tested this because I could imagine a mechanism that would make this happen, but the event didn't fire.

[Wandering Soulstar]

Thanks for the reply Nova ...

 

In followup to this, and based on the actual situation of what I am trying to do. What I'll actually be doing is loading the script mentioned into another prim, using llRemoteLoadScriptPin, and having delt a bit deeper into what the wiki says about this function it indicates:

'When the script is set to run (with running, the running checkbox or llSetScriptState) state_entry will be queued.'

Does this mean what I think, i.e. that the script will go through it's normal startup in the Default state? Even if when it was stopped it was in another state?

[LepreKhaun]

---

Wandering Soulstar wrote:

Hi All,

Question regarding a script detecting owner change. Now I understand clearly from the Wiki that I can use the changed event with the CHANGED_OWNER flag to check this, but I have a specific scenario in mind:

• I own the script and the prim it is in.
• I Set the script to not running
• I then give the prim and script to another
• They then start the script running

 

?? Will the changed event then fire ??

 

Thanks in advance!

Wanda

 

---

 

Events, in their truest sense, are messages. The code in our LSL scripts have Event Handlers contained within States. When a State becomes active in a script, the script's Event Queue is cleared and the Event Handlers of the active State are registered with the server. Only registered Event Handlers can have an Event placed into a script's Event Queue.

 

A script that is not running has no State active, no Event Handlers registered and, for that matter, no Event Queue to receive Events. This differs from a running script whose object is taken into inventory.; it's changed() Event Handler (if it's within an active State) remains registered and it also has an Event Queue which awaits processing until it is rezzed.

[LepreKhaun]

---

Wandering Soulstar wrote:

Thanks for the reply Nova ...

 

In followup to this, and based on the actual situation of what I am trying to do. What I'll actually be doing is loading the script mentioned into another prim, using llRemoteLoadScriptPin, and having delt a bit deeper into what the wiki says about this function it indicates:

'When the script is set to run (with

running

, the running checkbox or

llSetScriptState

)

state_entry

will be queued.'

Does this mean what I think, i.e. that the script will go through it's normal startup in the Default state? Even if when it was stopped it was in another state?

---

Correct, the default State is always activated from scratch when a script is reset by any means and its state_entry() Event Handler will always take precedence in the Event Queue,

[Wandering Soulstar]

Thanks LepreKhaun ... seems then like my base problem is solved. Since I'lll be sending the script to the new prim with llRemoteLoadScriptPin .. setting the running flag to TRUE, the script will 'restart' in the default state, executing state_entry, where I can grab Owner.

[LepreKhaun]

I feel a lot of difficulty in understanding the LSL event model is due to a pervasive looseness of the term "event" being used in place of a number of phrases that contain the word "event". Unfortunately, this looseness dates all the way back to the initial LSL language definitions and probably isn't changeable at this late date.

 

I try to distinguish the differences in my own writing by, for instance, referring to the touch_end() "event handler" rather than the touch_end() "event" unless I'm actually talking about the message itself. Otherwise, the reader requires a certain level of understanding to correctly read what is being written in the context they find "event".