Prim Keys

[Wandering Soulstar]

Hi All,

Another question, one I could test inworld but do not expect to be back in world for a while and will have some down time o script offline later on so .... and I am pretty sure of the answer but just wanted to double check.

I need to use the key of a prim in my code for a few reasons, so in my script I grab this. Am I correct in assuming that should I take a copy of the prim into my inventory and then rez it, that the copied prim will have a new key?

 

Thanks!

Wanda

[Dora Gustafson]

You are right in your assumption

:smileysurprised::smileyvery-happy:

[Wandering Soulstar]

Thanks for the confirmation Dora ... so much for being efficent and grabbing it only once at script start.

[Nova Convair]

There is no script start. There are only events.

You want to be efficient and grab it once in the on_rez event.

[Wandering Soulstar]

Nova .. I was using Script start to refer to the state_entry event of the default state, which is the very first event that is executed when a script starts for the first time or is reset.

[Miranda Umino]

Why not to set your key via llGetKey inside your on_rez event ?

[Wandering Soulstar]

Hi Miranda ...

 

Reason is because the script could be in a not running state and so no on_rez event would be called. In any case this is tied with a few of my other posts today and so summing them all up I believe I have a clear way forward.

Thanks for your response!

Wanda

[Miranda Umino]

so , to test if the last key exists in the sim  ?

if it does not , to refresh with llGetkey ?

 

key myVariable;......if ( llList2Vector( llGetObjectDetails(myVariable, [OBJECT_POS ] ), 0 == ZERO_VECTOR )myVariable = llGetKey();.........

 

or faster :

key myVariable;........if ( myVariable != llGetKey() )myVariable  = llGetKey(); ????

 

[Wandering Soulstar]

Could do .. but having reviewed the code found that it is much simpler to just use llGetKey ... not too many places actually where it is used so the efficency savings were probably fairly minimal.

[Johan Laurasia]

on_rez() should only be used when you want to do something at the point at which the object is rezzed.  state_entry() when you want the function performed every time the script is ran.  In this case it would be proper to use state_entry, not on_rez.  While both would work, the on_rez version would break if the script was simply reset.  For any script where you're grabbing keys it's prudent to grab them each time the script is ran, not rezzed, hence, use state_entry().

[Dora Gustafson]

---

Johan Laurasia wrote:

on_rez() should only be used when you want to do something at the point at which the object is rezzed.  state_entry() when you want the function

performed every time the script is ran

.  In this case it would be proper to use state_entry, not on_rez.  While both would work, the on_rez version would break if the script was simply reset.  For any script where you're grabbing keys it's prudent to grab them each time the script is ran, not rezzed, hence, use state_entry().

---

The state_entry() is not run every time the script is run.

It is only run when a state is entered, hence the name.

If the default state has a state entry event handler then that state_entry() is run every time the script is reset because a reset will enter the default state

:smileysurprised::smileyvery-happy:

[Miranda Umino]

Yes , but Wandering SoulStar  wants to use llRemoteloadScriptPin

So the state_entry   will be the first event triggered .

And llGetStartparemeter will know wich parameter we have sent to llRemoteloadScriptPin

[LepreKhaun]

---

Miranda Umino wrote:

Yes , but 

W

andering SoulStar  wants to use 

llRemoteloadScriptPin

So the state_entry   will be the first event triggered .

And llGetStartparemeter will know wich parameter we have sent to 

llRemoteloadScriptPin

---

You're missing the point- state_entry() is an event handler that may be used in any state. Only the state_entry() specifically within the default{} state is triggered on reset. This does not apply to any other state's state_entry().

 

Dora was making a necessary clarification of this so beginners reading the convo become aware of the difference and not wonder later why their state_entry() in (say) state working{} isn't being triggered on reset. Because it won't, that .state_entry() will wait to be triggered until the working state is later entered.

[Johan Laurasia]

I disagree.  If you make a prim, click new script, open up the script, and start pounding on the reset button, it will print "Hello Avatar!" each time you hit reset. therefore, since the llSay(0,"Hello Avatar!"); function is in the state_entry(), then the handler must be triggering.  I don't know any other way to say it, when you reset a script, state_entry() in the default state is triggered.  Try it if you don't believe me, I've been scripting in LSL for quite some time.

What you're saying is true, it's just that when you hit reset, if the script is set to run, then it begins running which triggers the default state to be entered which triggers the state_entry() handler.  The default state IS a state...

Johan

[arton Rotaru]

What Dora, and LepreKhaun is saying, is that you don't necessarily have to have a state_entry event handler in the default state.

[Johan Laurasia]

Well the default state is assumed, additional ones are not and need to be mentioned.  What was being discussed was when to use on_rez() vs state_entry().  The information I gave didn't mention any states, so the default should be assumed, no mention of other states was given.

Therefore... in the interest of completeness, When a script is reset, should a state_entry() exist within the default state, it will execute when the script is ran, on_rez() will not.  No other state_entry() handlers in states other than default will be triggered.