Jump to content
Sign in to follow this  
Wandering Soulstar

Prim Keys

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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(); ????

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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().

Share this post


Link to post
Share on other sites


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:

Share this post


Link to post
Share on other sites


Miranda Umino wrote:

Yes , but 
andering SoulStar  wants to use 

So the state_entry   will be the first event triggered .

And llGetStartparemeter will know wich parameter we have sent to 

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.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...