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

LSL Wiki : llRezObject

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are
llRezObject(string inventory, vector pos, vector vel, rotation rot, integer param)

Creates ("rezzes") object's inventory object centered at position pos (in region coordinates) with velocity vel and rotation rot. The param value will be available to a script within the newly created object in the on_rez event or through the llGetStartParameter function. The vel parameter is ignored if the rezzed object is non-physical.


If inventory is not contained within the object, the script will say "Couldn't find object foo" where foo is the value passed to inventory.

If inventory exists, but is not an object, the client will see an error dialog in the lower-right of the screen saying "Unable to create requested object. Object is missing from database."

Performance Advisory
Always use temp-on-rez when rezzing a large number of "disposable" objects such as bullets or other projectiles. Doing this allows them to automatically be cleaned up, should they break or encounter no-script land. This is both good scripting practice, as well as good for your sim and neighbours. It also keeps you and your customers happy by not getting complaints sent after them.

llRezObject triggers the object_rez event, passing the new object's key to any script in the rezzing object. The newly rezzed object will receive a on_rez event. This is useful for replicating objects.

Use llGetPos() + offset to specify a position relative to where the scripted object is.

When rezzing an object that is a linked set, pos specifies the geometric center, which can be determined with llGetGeometricCenter (when called from the object that is to be rezzed, so store this information somewhere if it's needed). For some scripts llRezAtRoot may be desired since it rezzes the object's root prim at location pos.

Rezzing an unlinked set (multiple objects/prims that were taken as one inventory item, but aren't linked together) is possible, but a rot other than ZERO_ROTATION will give unexpected results (the individual objects will be rotated but their positions won't match the rotation).

// rez something 2m above us
llRezObject("something", llGetPos() + <0, 0, 2>, ZERO_VECTOR, ZERO_ROTATION, 42);

If you attempt to rez a large number of objects within a short period of time (such as using multiple scripts to circumvent the 0.2 second delay) or you rez a self-replicating object, you may run into the Grey Goo Fence, which attempts to slow grid attacks.


Recoil is applied to the rezzing object/avatar when it rezzes a physical object with a velocity. Large objects rezzed with a large amount of velocity will push with a large amount of force onto the rezzer, while a small object with small velocity will give negligable force (for every action there is an equal but opposite reaction). The formula for finding the force is:

-(velocity of rezzed object * mass of rezzed object)

Use this in a llApplyImpulse statement to counteract the recoil.


If the inventory object that is to be rezzed has copy permission, a copy of the object will be rezzed. However, if it doesn't have copy permission, the original will be rezzed and removed from the object inventory. Any subsequent calls to this function with the same inventory will then fail because the inventory object is gone. It's important to set copy permissions for the next owner if an object is to be sold (or given away) and is rezzed by llRezObject (unless only a single copy is rezzed).

If the inventory object that is to be rezzed does not have copy permission, and the object containing it is attached, the object will not rez, and result in the following error / warning : "Can't rez no copy objects from an attached object."

Note: the changed() event will not be triggered when a no-copy object is rezzed from inventory.


Q: llRezObject doesn't rez the object or return an error. What's going on?
A: You may have specified a pos that's outside the 10m range. This is the only situation where llRezObject will silently fail.

Q: Really? That's stupid. How do I figure out if my pos is within the 10m range then?
A: Use llVecDist beforehand.

Q: I give up, why "llRezObject"? Why not "llCreateObject" or "llSpawnObject"?
A: "Rez" comes from the 1980s movie Tron. Hey, nobody ever claimed the Lindens weren't geeks.

Q: It's not working. It says my object can't be found.
A: You have to make sure the object you're trying to rez is actually in your object's inventory and named the same both in the inventory and the script.

See also: llRezAtRoot and ExperimentllRezObject

This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Functions | Inventory | object_rez
continue reading
online casino
click this link
read more
Comments [Hide comments/form]
llRezObject("something", llGetPos() + <0, 0, 2>, ZERO_VECTOR, ZERO_ROTATION, 42);

42? This is rezzing something related to the meaning of life the universe and everything?
-- SuezanneCBaskerville (2005-05-02 22:35:51)
"The maximum distance an object can be created at is 10 metres in any direction."

Measured from where? It doesn't seem to be the position of the root object. Might be the geometric center of the linkset?
-- SeifertSurface (2005-08-07 15:48:38)
Nope, not that either. (In a very unscientific test) I can rez an object at 11.3 meters from the root position, and 10.3 meters from the geometric center... but not at 12.2 (from root) or 11.2 (from geometric center). *shrug*
-- SeifertSurface (2005-08-07 15:57:25)
I noticed a particular peculiarity with llRezObject: I think the size and mass of a prim has something to do with the speed at which it's rezzed. I was builiding a gun and I had detected a noticable change in the rate of fire anytime I altered the bullet size. With an initial mass of 0.01kgs, the gun was a bullet hose, but when I changed the prim arrangement to a larger root prim, the mass was 2kg and I had a slow and sometimes unsteady rate of fire. When I cut down the prim and shrunk it, I noticed it got faster.
-- BondHarrrington (2005-08-23 13:07:55)
I think some of the info on this page might be incorrect. At least in the current version (1.6.12) anyway. A bit of experimentation showed that the rezzed object is positioned with its <i>bounding box centre</i> at the specified position - not the geometric centre. Assuming the geometric centre means the average position of all the prims in the link set, which I think it does. Annoyingly when you rez an object with a rotation, it places the unrotated bounding box centre at 'pos' then rotates the object about its root. Can anyone else confirm this?
-- FrimkronPascal (2005-09-16 02:57:12)
I can confirm what Bond experienced. Seems to be a mass related addition to the delay. Didn't used to be like that as far as I can remember. Must have been slipped in at some point. When I have more info like effects of multiple scripts, effects of velocity, details on delay times, etc. I'll update the page. Unless someone else already has the info ;-)
-- ReadyJack (2005-10-06 01:35:36)
Probably to 'counter' the trick of rezzing a 255-prim 'projectile' and that delinks itself on rez and all the sub-prims 'fire' themselves when they're delinked.
-- WolfWings (2005-10-06 12:50:10)
Regarding the apparent delay with larger objects vs. small: is this perhaps related to Energy? The object is rezzing the bullets (or whatever), then effectively applying an impulse to give it velocity (and maybe even to apply the recoil to the user)- maybe this is consuming energy? (Note the Energy entry doesn't specifically list llRezObject as one of the dynamics functions that consume energy.) Do these delays with larger mass bullets happen if the bullets are rezzed at zero velocity, or only when they're launched at speed? Are the delays shorter when the gun itself is more massive (and thus has more energy to spend)? If the slow and unsteady rate of fire only happens with moving bullets, perhaps it's an energy issue, and the rate of fire is hobbled by the energy capacity and regeneration rate of the prim with the llRezObject script. Maybe the script is calling the llRezObject command on schedule (every 0.1 seconds), but the prim doesn't have sufficient energy to run the operation, especially after firing multiple shots in rapid succession. This leads to the question of whether the object rez just silently fails, or if it is delayed until the prim energy is sufficient to run it.
-- MoriashMoreau (2005-10-18 13:29:12)
I'd like to further Seifert's comments about the arbitary 10m rule. I've successfully rezzed an object at llGetPos-<0.95, 4.75, 7.7> which ought to be 9m away from the rez point. However increasing the offset to <1, 5, 7.7> fails - but SL and I both calculate the distance to be 9.2m.
-- EloisePasteur (2005-10-30 05:59:16)
llRezObject fails (usually) when the parcel is full. It does not raise a script error, but instead sends an error message to the task owner.
-- PatchLamington (2006-04-26 07:46:22)
Is that huge bit of redness neccessary? I agree that it's an important point but that seems like overkill.
-- ReadyJack (2006-08-27 03:27:10)
I think the huge bit of redness is appropriate. It's an important rule to observe when using llRezObject().
-- CrossLament (2006-08-30 13:33:32)
it's a good thing imho.
-- BlindWanderer (2006-08-30 23:06:48)
I decided to go with the giant red box after talking with a few of the Lindens about it. We decided it was simply that pressing an issue, given the crap it was doing to the grid.
-- CatherineOmega (2006-09-03 22:18:53)
Is there a way to tell the rezzed object the key of the object that rezzed it? I want the rez-er and the rez-ee to communicate by filtering the key, not the message, name or channel. If there's no way, I guess I could pass a random integer in the start parameter of llRezObject as the com channel. ~~~~
-- CiscoLane (2007-08-01 13:27:19)
object_rez event?
-- (2007-08-21 22:16:17)
Well, no. That gives the rez-er the key of the rez-ee. I want the rez-ee to have the key of the rez-er. The way I do it now is to have the rez-er say the key of the rez-ee. When the rez-ee hears its own key, it just has to check the key of the sender to know the key of the rez-er. Not exactly foolproof or secure, but it works.
-- (2007-09-04 08:31:03)
Attach a comment to this page: