Best Practice For Script Startup

[GManB]

I am seeing examples where llResetScript() is called in on_rez and this seems to give nice stability to the code. Is this practice common and is it good?

I would really like to pass an integer to an object being rezed by another object so that the second object can be identified by that integer by the rezzing object to use for bookkeeping. However, the start_param of on_rez is lost, I have read and experienced, when llResetScript() is called even if I save start_param in a global in state_entry. The same issue happens with llGetStartParameter(). Thus, it seems that calling llResetScript() in on_rez eliminates the possibility of passing in an integer.

Is there another place to call llResetScript() that would allow me to input the integer or is there another method of getting something to an object being rezzed?

 

Thanks,

G

[Mollymews]

what we can do is store the start_param in a persistent store like the object description field: http://wiki.secondlife.com/wiki/LlSetObjectDesc

then reset the script. Retrieving the start_param from object description in state_entry event. http://wiki.secondlife.com/wiki/LlGetObjectDesc

[DoteDote Edison]

Write the variable to the description of the prim, then llResetScript().  If you want to conceal that variable, write it, reset, then get description, then replace description with empty or whatever else.

In other words, ditto to the comment above.

Edited September 29, 2020 by DoteDote Edison

[Rolig Loon]

To the point of your initial question .... no, there's no particularly good reason for routinely restarting a script on rez unless:

1.  You want to be sure that all global variables are set to their default values (usually zero).

2.  You want to be sure that the object owner is current.

3.  Physical parameters like temp_on_rez designation, phantom, and physical status are set to predictable initial values.

If you don't care or, more importantly, if you don't want those things reset, then don't reset the script.  Personally, I'd rather not set a one-size-fits all rule unless one size really does fit all.  Otherwise, I'd just be potentially causing trouble for myself.

[Phate Shepherd]

One thing to be mindful of when doing resets on anything that is attached or sat on is to re-aquire run-time permissions like PERMISSION_ATTACH and PERMISSION_TRIGGER_ANIMATION after the reset if used. I quite often check in my state_entry event to see if the object is attached, and if it is, request PERMISSION_ATTACH again. This not only makes the item resettable while worn, but it lets you edit the script while worn, and not trigger permission errors when you issue a llDetachFromAvatar().

On the other hand, for items that use PERMISSION_TRIGGER_ANIMATION, I frequently reset the script when the avatar stands up, prepping it for the next person, rather than resetting it when they sit.

As Rolig said, there is no one-size-fits-all approach to how a script starts up. There are so many little gotchas here and there, it can be a long time to instinctively know what will work best.

Edited September 30, 2020 by Phate Shepherd

[Phate Shepherd]

2 hours ago, Mollymews said:

what we can do is store the start_param in a persistent store like the object description field: http://wiki.secondlife.com/wiki/LlSetObjectDesc

then reset the script. Retrieving the start_param from object description in state_entry event. http://wiki.secondlife.com/wiki/LlGetObjectDesc

Be mindful to not use link number 1 for this on attached items. If I recall right, link 1 cant have its description or link name changed by a script while attached.

[Wulfie Reanimator]

8 hours ago, GManB said:

I would really like to pass an integer to an object being rezed by another object so that the second object can be identified by that integer by the rezzing object to use for bookkeeping.

Instead, I would recommend the object_rez event. It's triggered whenever a script in that prim rezzes an object, and the event tells you the UUID of the object that was rezzed. You can easily add this UUID into a list for bookkeeping.

[Xiija]

Some people use an init() function instead of resetting.

you can reset variables there, and it saves you from having to reset the script all the time.

 

[GManB]

6 hours ago, Wulfie Reanimator said:

Instead, I would recommend the object_rez event. It's triggered whenever a script in that prim rezzes an object, and the event tells you the UUID of the object that was rezzed. You can easily add this UUID into a list for bookkeeping.

Wulfie,

I, think, I actually need the opposite (and I have experimented with on_rez), Here's more detail on what I am trying to accomplish, in case someone sees an issue or there a simpler way. . There are up to 17 objects involved, 8 chairs (sit targets), a main scoreboard, and up to 8 HUDS. The chairs tell the board the chair number and the av key. The board rez's the HUD and tells it (via the on_rez start parameter) the chair number. This binding of chair number (and, thus, av key) and getting the seat number to the HUD happens atomically in a listen event in the board so I don't have to consider ordering of avs sitting and the binding to a HUD. My first implementation did indeed use lots of lists to keep track of things but it was gettign complicated. Once I learned how to reliably get a datum from the rezzer to the rezzzee the code became much simpler and straightforward.

What, I guess, I am concerned about is the temporal ordering of events in the underlying runtime if, e.g., two av's sat almost simultaneously) the board would get the events in some order. Now the binding of seat to av key is ok, that's fixed but the board, without some tricky bookkeeping, doesn't know the order of arrival. Then, the rezzing of HUDs occurs in the order the sit events arrived but I am unsure about whether the underlying system guarantees the ordering of the object_rez event. By passing the seat number to the HUD on rez I eliminate this temporal ordering issue ( I think )..

G

[Rolig Loon]

Or .... you could rez a HUD, do a quick handshake to give it the av's UUID, and pass the HUD to the avatar.  As the HUD attaches, have it check the number of the seat that the av is on, and then send that info back to the board.  With that final step, the board has confirmed (a) that the av is seated, (b) that the HUD is attached,  and (c) the seat number.  I think that avoids having to worry about timing.

[GManB]

24 minutes ago, Rolig Loon said:

Or .... you could rez a HUD, do a quick handshake to give it the av's UUID, and pass the HUD to the avatar.  As the HUD attaches, have it check the number of the seat that the av is on, and then send that info back to the board.  With that final step, the board has confirmed (a) that the av is seated, (b) that the HUD is attached,  and (c) the seat number.  I think that avoids having to worry about timing.

The rezzing of a HUD could proceed at very different rates in different viewers, no? Say the order of sitting is av A then av B. The board gets two listen events from the two seats and order doesn't matter here because the incoming message contains both the seat number and av key. So board rezzes two HUDs in some order. But, when the HUDs fully rez and respond to the handshake the events could arrive at the board in a different order from that which the board rezzed them, just due to user system/viewer relative speeds.

By passing the seat number in the llRezAtRoot() call there is no possibility of mis-ordering because the binding of the seat number to ak key is atomic in the board script and the HUD always includes the seat number in its messages to the board.

 

G

 

[Rolig Loon]

Yes, I see that, and it's a good approach.  As an alternative, I'm suggesting that you collect the seat number as the final bit of information (or at least confirm it then) instead of relying on grabbing the seat number at the start. Then you can be sure of exactly which seat the avatar is sitting on, and you don't have to worry about the timing issue..  

[GManB]

1 hour ago, Rolig Loon said:

Yes, I see that, and it's a good approach.  As an alternative, I'm suggesting that you collect the seat number as the final bit of information (or at least confirm it then) instead of relying on grabbing the seat number at the start. Then you can be sure of exactly which seat the avatar is sitting on, and you don't have to worry about the timing issue..  

Ah, I think I finally see the point you are getting to. It doesn't matter that the board rezzed a HUD as a result of a message from seat x because the HUD can be unbound. It isn't youare saying, necessary to bind a HUD to an av until the HUD gets the av key and requests permission. I actually do something similar in a different version of this code where the participating avs are not sitting, e.g,. at an event. The board just rezzes a bunch of HUDs and the avs click on one to make the binding between HUD and av. It's a little more bookkeeping but more general, I agree.

G