Open Letter to Phillip on llRezObject

Philip,

It's been a long time since I took part in a focus group call with you, other members of your company, and a group of fellow residents. At the time, you said we should email any follow-up comments we came up with later. Well, it's taken me a long time to get around to writing you about this topic, which was only lightly touched in the last moments of the meeting. I also mentioned it at one Town Hall meeting in-world some time later.

I'd like to say a few things about the llRezObject function and how it is implemented and used.

By far the largest use of this function, at least in terms of actual numbers of scripts in the world, is to make and fire bullets. The function itself seems to have been originally designed with this in mind, what with the inclusion of the velocity vector. Bullets are very simple objects, often just a single prim, but can be linkages of objects such as detailed arrow or cruise missile. For such a use, the exact placement of the object isn't very important since, even before it becomes fully visible, it is immediately in motion and moving away from where it was initially positioned by llRezObject. For this purpose, the llRezObject function was perfectly designed... Almost to the point where the name llRezBullet would have been just as appropriate.

But while there are many, many gun-like scripts in the world, there are many, many other uses for which residents would (hope to) use llRezObject. But they have found, as have I, that those properties that made it work so well for bullets make it very difficult to use for other tasks, such as: rezzing furniture only as needed, auto-assembling builds too big to link, creating procedural objects like large curved walls out of code-shaped and positioned prims, theme-ing a room to day/night or social use ("rez surprise party", or for virtual sets on a stage or something like my Timeplunge ride.

There are three main things that make it so difficult to use. First and foremost is how it calculates position and applies it to the rezzed object when the object is a group of linked primitives. If the position vector provided to the function was <100,100,100> then checking the position of the rezzed object afterwards will find that that is NOT where it is. That's not where the head prim of the link is either. Nor is that where the XYZ-axis-edit-arrows are located if the object is selected in edit mode. It's not even the object's physical center of mass. The only significance to the <100,100,100> point is that it is the average center of every prim that was rezzed.

Now I think today I figured out why this is, and it's why I finally got around to writing this up. It is possible to select several objects (some of them links, some just single prims) and Take them into your inventory as a single "inventory object" then give this to llRezObject. Since there is no single "head" prim in this case, there is no well-defined point to use as the "center" for positioning purposes, so an average center is used. While this keeps the function from breaking, it is because this average center is used even when there is only a single linked object that makes it next to impossible to accurately position a rezzed, linked object using llRezObject.

A second related problem is the rotation, which, at least for single, linked objects, rotates around the head prim of the link. It is applied AFTER the object is positioned, and since it rotates around some point other than the position given (<100,100,100>, by the time it is done, the rezzed object is some OTHER location... Not even the messed up position it would be at otherwise.

Third and not the least, by far, is the fact that the starting parameter is just a single signed integer. This really should be a string. With all the oddness of position and rotation, many complex scripts give zero vectors for those parameters and instead script the rezzing objects to move and rotate themselves in a controlled fashion. To this end, they need to be told where the rezzing object is so they can position themselves correctly, what rotation they should have, and any other information pertaining to size, shape, texture, color, or other bits of information their scripts may need. This can NOT all be packed into a single unsigned 32-bit integer. Xylor (you know the chap... makes some great text display systems among many other things) made several objects that create large rounded shapes like geodesic spheres or circular floors tens of meters in diameter. This requires the generic prim to be given a lot of information, more so now that we have llPrimitiveParams and don't have to do so much by hand. His code would pack the height, width, and depth of the prim into the integer param, but there's only a bit or two left after that. No room for any more useful information.


What is needed is a new rezzing script function (so that scripts that use llRezObject don't break) that addresses these issues. My suggestion as posted in the forums today has more features than are really needed, but I'll list it here along with the bare bones version. I call it llRezSingleObject to both change the name, and to point out that it only rezzes one "object". If several objects were selected and Taken and passed to this function, only one of those objects will actually rez. (Doesn't matter which, since this could just as easily give a run-time error. Rezzing only part of the "inventory object" is a graceful failure.) For single prims, it uses the prim's position as its center. For links, it uses the head prim's position as center. The user parameter is a string.

llRezSingleObject( string name, vector pos, rotation rot, string params );


A more controllable version adds flags to change the pos or rot from global coordinates to the local coordinates of the object that contains the rezzing script, as well as the velocity vector and a flag to make it use coordinates local to the rezzed object or global coordinates.

llRezSingleObject( string name, vector pos, integer pos_is_local, vector vel, integer vel_is_local, rotation rot, integer rot_is_local, string param );


This second version may be overkill, but the velocity vector may be useful to some. (But bullets are still best created with the old llRezObject function, a.k.a. llRezBullet.


This is a rather long description of a problem with a single function in Second Life, which might seem like a very small piece of a very large (and growing) virtual world, but this has been my biggest beef with the LSL language since I first started using this function months ago. As my Timeplunge ride shows, it IS possible to use the current llRezObject function, as it is, to do all that I mentioned in this email and more... BUT, I know from having MADE Timeplunge that it is FAR more complicated than it needs to be. It took me hours to find ways to accurately position the set pieces so that they seamlessly lined up. Because llRezObject basically works, however badly, it has not been changed, updated, or replaced, despite many forum discussions about the function's problems.

I'm bringing this to your direct attention, Philip, in a hope that something may soon be done, as time allows. I know that work has begun on version 1.4, and that including Havok v2.2 is a major undertaking (people where I work have recently made the same switch). If something can be done, I understand if it can't be done before 1.4 due to source lock-down... But if there IS to be more 1.3.x, perhaps (and I'm wishing here, most fervently) something like llRezSingleObject could be implemented. Version 1.3.5, perhaps? (Okay, that probably counts as all three wishes.)


Thanks for making such a wonderful world to play in, and for making it more wonderfull-er every day.

~ Tiger Crossing
~ Chris Innanen

P.s. I'll be posting this to the forums as well, to make sure I have some sort of public support on this. Feel free to check in on that thread to count "I support this product and/or service" and "We don't need this crap!" responses.

P.s.s. (Ignore those posts that include both responses... They are just being silly.

EDIT: Repeated misspelling!

*claps wildly* Yes, PLEASE add a function to fix this issue. This has been a very annoying bug for waaaay too long.

One suggestion though, I'd recommend just using 1 boolean to set local or global coordinates. Yes there are some instances where having them split up would be nice, but the overhead of having 3 boolean parameters for this isn't worth the extra length of the call =P. You can fairly easily just calculate this yourself, if your parameters are a mix of global and local.

Bravo, Tiger, for the well written suggestion =)

Xylor

*cheers*

And perhaps the rez should behave like particlesystem and setprimitiveparams. With list implimentation instead of all those individual options, it might be more efficient. They seem to like lists, so it must be for a reason. Would make the boolean thing moot, if I understand it correctly.

Correct me if i'm wronge but can't you just have the first prim be at the average center? then it should rezes at the correct location and rotates around the center.

Only if you're doing something where you can afford the extra prim that takes. If you're rezzing a 50-piece party set, those 50 extra prims are going to get annoying fast.

You'd have to figure out the exact center of a bounding box defined by the centers of every primitive in the link set, and then put your root primitive there. I once tried to put a huge three-story, ~160-prim spaceship with six hull segments into a rezzer. Trying to calculate the exact geometric center of a single group of 30 or so objects would be a daunting task. Doing it six times would drive me to drink.

I fully support this feature and/or idea.

Seriously, I just drove myself batty with some autorezzers.

edit: change this to english. really batty.

I endorse this idea/feature/letter.

I agree, and add one more request to this: Return the key of the newly rezzed object!

Trying to get the key of an object that you rez is annoying at best. llSensor seems to be inconsistent enough that you don't always get a hit when you scan for the newly rezzed object.

- Neo

Never mind, I just read another thread and found out about object_rez() event. Ignore my rantings

Tiger, I could never have imagined a more well written post, bravo!

I agree with you completely, save for this little part:



I dont understand why a set of unlinked objects is so difficult for this function to work with. The function can simply treat the last object selected as the 'parent' prim of the set of unlinked objects, something the inventory system already does (the last object selected gives the set its name when it is taken into inventory). Having the system treat the set of unlinked objects like a set of linked objects while they're being rezzed eliminates any ambiguities.

Now, since the name of the function was determined by the property I just disagreed with, Ill propose a new name

llRezObject2

Plus, when I first read your suggestion with llRezSingleObject, I assumed that it couldnt rez linked sets, so this naming smooths out another lump in the suggestion.

Also, you kinda forgot to mention the changes LL would need to make to the event llRezObject2 triggers in the rezzed object.

Perhaps something like:

on_rez2(string parameter, key rezzer)

Where parameter is the last argument of llRezObject2, and rezzer is the key of the object that rezzed this object.

Or if that's not simple, something along the lines of

on_rez2(string parameter)

is adequate.

==Chris

I usually use the integer as a channel number and then pass all the info i want through it.
I certainly wouldnt mind a better, more featureful rezzing function, with one of those parameter list APIs like we have in llParticleSystem.

That's very true, Chris! Since there aren't any "2" function names, and I'd hate to get them started down THAT ugly road, I'll try to think up a new name. Making it plural would make sense, but it's not different enough... Hmm. Okay, got one.

Let's pull all the ideas together again:


llRezObjectExact( string name, vector pos, vector velocity, rotation rot, integer local_to_rezzor, string params );

name = a named inventory item or a key

pos = an offset from the rezzor's position on a globally-aligned axis or (if the local flag is true) an offset from the rezzor's position on it's local rotated axis

velocity = the initial velocity of the rezzed object in global coordinates or (if the local flag is true) extended along the rezzor's rotated axis.

rot = the rotation of the rezzed object in global space or (if the local flag is true) a rotational offset to be combined with the rotated position around the rezzor

local_to_rezzor = a TRUE / FALSE flag to make all the previous parameters local to the rezzor's position and rotation.

params = a string that is passed to the rezzed object that can be parsed.


And yes, there would need to be a new on_rez_exact or something similar to receive the string parameter.

(Overloaded functions and handlers would be an addition that would make upgrades to the LSL language MUCH easier, you know...)

I endorse this proposal. Let's see in in v1.3.6!

yes please!

YES!
I think someone should start a new feature suggestion asking for overloading

==Chris

Just to bump the params as a string.

Agree absolutely that params should be a string; ideally it will have a max length at least equal to that possible in linked messages.

Eggie, you say you can pass the channel number, but the problem is: if you're rezing multiple objects you dont know which one is talking to you So you gotta make a channel for each object, or pass a numerical reference to the object telling it which object it is, or rez each object at slightly different poses or rots etc etc

Much easier to be able to pass a string and just multiplex the parameters you want in that. You can still pass your channel number, but you can also tell the object who it's supposed to be

Azelda

Yeah az, that's what I do, different channels for each object.
For instance in my radar I have a sensor and rez a little stick figure for each person detected.
I use the sensor index as the channel number and then on each pass of the loop i send all of that person's sensed data to their respective stick figure.

You have to have a script in the rezed obejct to position itself based on something it listens for. There's a ton over overhead, complexity, and delays using the rez-shout-listen technique, all the more so when there are many objects being rezed. Not to mention that the player will SEE each obejct moving from it's rez location/orientation to it's final state.

It's not visually clean. It's harder on the system (listens, shouts, moving all about). It takes more scripts. It takes longer scripts.


Just by creating the command proposed here (which, it seems, is heartily approved of by all) it can just be ONE LINE.

I never said I disagreed with you Tiger

Oh, I wasn't really preaching to YOU, Eggy... It's the ones with the power to change things for the better that I want to hear that.

Don't want a Linden to think "Oh, Eggy's got the solution they need. My work here is done. To the LindenMobile!!!"


We really need this.

I'd like to constructively bump this thread by adding an argument against a certain parameter in the function above.

The local_to_rezzor parameter is definate overkill. If local positions/rotations/velocities are necessesary, they can be *easily* (when I say easily, I mean easily, I suck at math) computed using already known values.

That said, I am still in support of the fixes and string parameter that this thread proposes.

To throw some wood on the fire what about rezzing objects that are in a group but not linked. Rezzing them with RezObject sets all of them to the same rotation. I think the rotation should be only set to the base object and then the rotation between the old rotation and the new one should be applied to all the other objects (and properly positioned too). The current way this works i see as a bug and not a feature.

Oh i also support a local rez feature but not passing a string as a start paramater. I would like to see this instead.

llRezObjectExact( string name, vector pos, vector velocity, rotation rot, integer local_to_rezzor, integer params, string message );

where message is passes as a link message to the object with the key being equal to the object that rezzed it and the integer param being the start paramater. So it would be equivilant to:

llLinkMessage( LINK_SET, params, message, parent);

so you say why don't i just link it and do that? I do; but linking and unlinking has a small probablity of crashing the sim. And if you do a couple thousand links and break links the sim *will* crash.

llRezObject and object_rez works GREAT for me and I do not want a slower pig of a newb replacement.

Surprised to see this old thread come back to life. There have been many other llRezObject complaint threads since I started this one. (And this started the whole "Open Letter" trend, too. For that I'm sorry.)


LSL is slow. It's a virtual machine language. ANYTHING that puts more of the processing into the server C code and minimizes the length to which the script needs to perform extra processing is GOOD.

It is possible to work around every flaw in llRezObject with what we have now, but it is many, MANY times more complex than it needs to be. A few small changes to how we rez objects would simplify our scripts and speed up execution on the server.

Chris, your point about the local coordinates flag has been made in another thread and I agreed. While doing those computations in server-side C code would be a tad faster than doing them in LSL, it's a small savings and adds complexity most people won't use. I agree that flag is not needed.

Strife brings up an interesting point that deals with backwards compatability. The integer param should remain so that the on_rez handler needs no changes. But the string parameter could be accessed FROM the on_rez handler with a new function, llGetRezString, in much the same way that you can access the parameter with a function too.

My latest thoughts are along these lines:

llRezObject( string name, vector pos, vector velocity, rotation rot, integer param )

llRezStaticObject( string name, vector pos, rotation rot, integer param, string msg )

string llGetRezString()

The new llRezStaticObject will be more presice, handle rotations correctly, use the cetner of the root prim of the last obect in the group as the center of rotation and point of position, won't impart velocity on physical objects, and will pass a string accessable from the rezed objects' on_rez handler via the llGetRezString function.

Since the "name" being rezed may be several linked objects, each link's root prim need to receive the on_rez signal. (Or ALL the prims, however it's set now.) But the position and rotation set by the rez command should would on all of them together, just as if they were linked -- The same way they react if you drop them from your inventory while in edit mode and move/rotate them by hand.