Don't click here unless you want to be banned.

LSL Wiki : on_rez

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are
on_rez(integer start_param)

Triggered in an object whenever it is rezzed from inventory or by another object, or in an attachment when its owner logs in while wearing it, or attaches it from inventory. on_rez is not triggered when an object is rezzed after a teleport. For that, use a changed() event instead.

The start_param is the parameter supplied by llRezObject or llRezAtRoot in the script that rezzed this object. When rezzed by an agent, start_param is always 0.

start_param can be obtained anywhere in your script by using llGetStartParameter.

Note: on_rez still follows the rules of states. Remember, running scripts save their state when taken into inventory, and that placing them back in-world does not reset the script; it merely resumes the process. In other words, to get a script to execute a specific function regardless of state, on_rez must be present in every state. This means if a llListen is in an on_rez event, it will start a new listener, rather than remove the old one first. Avoid putting llListen in on_rez (or use llListenRemove first).

// this example can be used in a bullet that is rezzed by a gun
// if rezzed by the gun, supply a value != 0 to llRezObject

default {
    on_rez(integer start_param) {
        if (start_param != 0) { // if rezzed by gun
            llSetTimerEvent(5.0); // set die timer
        } // otherwise do not die after timeout, so we can still be rezzed for editing

    timer() {
        llDie(); // delete this object

Note: if using both on_rez and attach, on_rez will always be triggered first. However, if there's not adequate time to run everything in attach prior to detaching the object, the "detaching" part will run prior to on_rez:
default {
    on_rez(integer start_param) {
        llSay(0, "on_rez");
    attach(key id) {
        llSay(0, "attach");

Don't confuse on_rez with object_rez, which occurs in the object doing the rezzing using llRezObject.

Q: Is the on_rez event guaranteed to complete before any in-world interaction with the object can occur? For example, if a script had several calls within on_rez, could other actions on the object, like a physics event, affect the object before the event completed? Bullets that only change their physical state on rez still seem to be impelled by the force passed to the llRezObject function. That seems to indicate that the physics are turned on in the on_rez event of the bullet before the impulse is applied by the gun script.
A: Probably what is happening is the force applied is given a time-to-live and if this time is exceeded, the force is stopped. If an event is already being executed when an object is being rezzed, then on_rez will be queued.
A2: Usually, objects that need to be rezzed with an initial velocity already have physics enabled when placed into the rezzing object's inventory.

Q: Is on_rez triggered when duplicating an object by hand with shift-copy? I remember it used to, but it's not doing that at all. The following won't even work with shift-copy.
on_rez(integer bla){
    llOwnerSay("I've been rezzed");
A: This happens when you do a shift-copy, because the script resets. It's a new object that's first rezzed, then the script contained within it is started. state_entry is called, because the object has already existed when the script starts. If an object is taken and the owner has copy permission on it, and then rezzes that object via script or from inventory, it will have the same script state as when it was taken, including script permissions.

Q: Is there an event that runs when the object is deleted or taken into inventory?
A: No. The attach() event will be triggered when detaching an attached object, but that's it. If you're wanting to create some sort of cleanup function or to disable your object after use, use on_rez() and some kind of counter.

Q: Is there a way to get the key of the object or agent that rezzed this object?
A: No, not directly. The easiest way is to have the rezzer say something (for example a codeword) after executing llRezObject, and have the script in your rezzed object listen for it in chat. The rezzer's id will then be handed to the rezzed object's listen event handler. You can use a short llSleep delay in the rezzer object if your script isn't hearing it.

Q: How can I retain all the values in my variables and update llGetOwner while avoiding llResetScript?
A: Create a new function that removes and sets the llListen with llGetOwner. reference this function in state_entry and on_rez. This assigns a new owner to the listener but does not remove any data. Unlike llResetScript which resets the data.

Events | Functions | Rez
Comments [Hide comments/form]
events: on_rez VS attach
The on_rez Event is triggered before the attach event.
-- KurtZidane (2005-12-19 16:24:59)
The event on_rez is triggered by: teleports, rezzing from inventory, from object's inventory. When on_rez is triggered by teleport, The start_param value is 0.
-- KurtZidane (2005-12-19 16:28:21)
when triggered by teleporting, the event happens apone ariving to the new sim. Not leaving the old sim.
-- KurtZidane (2005-12-19 17:15:08)
It has been concluded here:
That if state change is the first statement executed in the on_rez event, it will be ignored.
(This is a bug in 1.9.0(21))
-- ChristopherOmega (2006-04-23 14:08:54)
If a script is stuck in an infinite loop, and contains on_rez(integer n){llResetScript()}, it *WILL NOT* reset if taken and re-rezzed! It will remain stuck in the inf-loop as LSL is pedantically single-threaded. An EXCELLENT solution by another scripter is to put in a second script that simply contains on_rez(integer n){llResetOtherScript("<name of first script>")}. This will reliable reset the first script from any(?) condition.
-- FremontCunningham (2007-04-13 13:44:43)
Attach a comment to this page: