Monica Balut

Thanks for pointing that out Qie

Seems to. Each part moves into position correctly in response to the heard llRegionSayTo command. I haven't actually had it chat the UUID of each object but it does what I need it to do.

Thanks for the insights everyone. After playing with this some more, I've decided the best way for the rezzer to communicate its position to the rezzed objects is by watching the object_rez event in the rezzer. When that triggers, I send the coordinates to the rezzed object via llRegionSayTo. It's all working fine.

From your description of the "keystone" object, that's what I was hoping to accomplish with the rezzer itself. I own Rez-Faux. It appears that the rezzer itself works as the keystone object much as I was hoping to accomplish. If that's the case, it has to communicate its postion to the rezzed set somehow. The only way I can think of accomplishing that is the way I described. My question really was about how the "anchor" and the rest of the objects should communicate. From your description, it sounds like your keystone object may be part of the coalesced set itself. If so, it seems like it would add another level of complexity for a user. Perhaps you could explain further if I've misunderstood what you mean. I'm not sure how that would work. The rezzer I am trying to make does not need the objects to follow the rezzer as Rez-Faux does, so I'm not too worried about that part. The intended purpose of this rezzer is more to rez an owner's objects on demand and not as a packaging tool to sell sets. And, BTW, I've never had much success in using moving_end. I've never seen it trigger reliably and from what I've read, others have had the same problem.

I want to be able to rez a coaslesced set via llRezAtRoot. The set seems to initially rez based on the location of the first object selected when that set was created and the others position accordingly as expected. The set also seems to unlink immediately when rezzed. What I want to do is have the parts of the set position themselves in a constant position relative to the rezzer. The rezzer can be in differnt positions each time. The final position may be well beyond the 10 m limit of llRezAtRoot. With single hard linked objects, I merely drop a positioning script into the objects which moves them into the correct position and rotation relative to the rezzer via llSetReginPos and llSetRot. The objects get their initial reference point by the fact that I rez them right at the rezzer at ZERO_ROTATION. They then move themselves to their remember position and rotation relative to the rezzer. It all works fine with single hard linked objects. However with a coalesced set, only the first object selected rezzes at that location. I have no general way of knowing which object of the set is the one that will rez at the rezzer and which will not. The other parts will rezz correctly relative to each other but since the rezzing point and rotation will differ depending on which part of the set rezzes at the rezzer, the other objects do no always rezz predictably with respect to the rezzer. It was suggested to me to pass this information via a rezzing parameter but there's just not enough information in an integer to uniquely identify the rezzer's loacation and rotation. Using a sensor is too blunt a way to approach this. The only way I can think is to have the objects broadcast a message on a unique channel to which the rezzer responds back via llRegionSayTo about its position and rotation. Then I would use this information to first move all the parts of the coalesced set back to the rezzer as would be expected and then go about positioning themselves as described above. Am I on the right track with this? Can anyone think of a different way to approach this? Is there some other way for the objects to know their postion relative to the rezzer when rezzed?

I guess coalesced is the correct term. I had only seen them referred to as "soft linked". But it does seem that a rezzer rezzes them unlinked and therefore they behave as separate object.

I'm building a rezzer that will rez objects that then move into position via a script movement command like llSetRegionPos. Although I can't find it documented anywhere, my impression is that soft linked sets don't behave the same way as hard linked objects do to script movement commands. With a regular object you just have to put in one script, say in the root prim, and when it rezzes at root the whole object moves into place. If I put a movement script in just the root object of a soft-linked set, the set does not move as a whole. Only the object with the script moves. It appears that, unlike when using the edit tools to move the whole set, moving it by script requires each part to be moved separately. The only way I've found to move a soft-linked set after being rezzed as above is to put a script into each of the objects of the set. Has this been the experience of others as well?

Thanks Cerise. That explains why it takes a few minutes for the reading to settle down. I've noticed that when an avatar first arrived in a region or when I first rez the object that measure this, script time is very high. Usually in about 3 minutes it settles down to a stable reading. I wonder why that first reading is so high.

llGetObjectDetails via OBJECT_SCRIPT_TIME "Gets the total amount of average script CPU time used by the object or agent, in seconds." according to the LSL Wiki. Over what period is the average taken? One time slice or more?

From my general observations, it's my impression that the timer event is triggered by comparison with the server's system clock. So, although time dilation may affect how rapid the script can execute something in response to the timer, the timer event itself is not that affected by time dilation although I would expect some delay if the system is thrashing from memory overload. Am I correct in this view? If not, could someone set me straight?

Qie, I did as you suggested and looked at Show Updates to Objects. There is a flurry of activity when the avatar just arrives to a sim and then it settles down, suggesting that only updates are sent after that. That would make sense. In spite of Geldsbard's and your excellent expanations, I'm still a bit confuse about the diffefference between agent time and image time. If textures are loaded from a central database and not via the sim, what then is image time. I had thought that image time was the texture download time.

Thanks. Best explanation I've seen so far. Does ALL that data get sent to each av during each slice? Or, does it just send updates? The reason I ask is that I often see a spike in agent time as new avatars arrive on the sim. One more, possibly related, question ... I thought that image time was the time required to send texture info up to the viewer, but you mention textures as part of agent time. So how is image time different from that?

I know that this is not specifically a scripting question, but I view this as the forum with the most knowledgeable people about the geekier side of SL. I've been trying to pay more attention lately to various parts of the Time secion in the Statistics Bar. I've read the wiki about it at http://wiki.secondlife.com/wiki/Viewerhelp:Statistics as well as a few other sites that come up in a Google search. Most of the lines are self explanatory but I'm left with one that eludes me, Agent time. The wiki defines that as: Agent Time - The amount of time spent updating and transmitting object data to the agents. What is this "object data" that is being transmitted? I can find no detailed explanation of what exactly that is.

Mesh clothing is starting to become the "must have" thing in the SL fashion community. The current system of having to provide a number of fixed sizes makes proper fitting very difficult. I understand that the lab had not anticipated how much mesh would be used for clothing. If they really want mesh to be more widely used, the deformer is essential.

I think I may have figured out the problem. In the group profile, Land & $ tab, it had me showing as donating 8835 m2. When I dropped that to 8704, my tier on my Land Use Fees page could be set at $40 again. So it turns out that my original calculation was correct. The tier is set based on what I donate to the group as set in the group profile and not on what I actually own. This was a rather frustrating process. There's no one resource that clearly explains all the steps you have to take to do this right.