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.

I just went to my account's Land Use Fees page. There it show that I have donated 8835 m2 to the group. I have no idea how that number was arrived at, since by my calculation I've donated 9600 m2. So Knowl, even the 8835 number is well below the 9574 you calculate, yet my tier is still calculated at $75 and the button below to select $40 is grey out. If I use the calculator on the above page and enter 8704 donated land and 0 owned land, my calculated tier drops to $40 as expected. If I raise donated land to 8705 my calculated tier goes up to $75. So Knowl, although your calculation make perfect sense to me, it doesn't correpond to what the calculator gives. It appears that tier is calculated as the tech described to me: I can donate up to 8192 + 512 = 8704 and still remain at $40 tier. Anything above that pushes me to $75.

I'm having some trouble understanding how the 10% group bonus applies to donated tier for mainland land. My aim is to personally stay at the $40 tier for my avatar. Here's how I thought it worked. Both my alt and I have premium accounts, so we each get 512 m2 for "free" to donate to the group. In addition, I bought then donated to the group an additional 8192 m2. All of this kept me in the $40 tier and my alt in the $0 tier which is what I want. Then I looked at the 10% group bonus thing. I assumed that the group would be able to own (8192 + 512 + 512) * 1.1 = 10137 m2 and still be ok. So I bought an additional 896 m2 and donated it to the group which brought it to 10112 m2, well below the 10137 I had calculated. This immediately threw me into the $75 tier. I contacted chat support for guidance. The tech pointed me to http://secondlife.com/land/pricing.php which seems to say that I can donate only 8192 + 512 to the group in order to stay in the $40 tier. (At lest that's how the tech interpreted it for me.) If that is correct, I don't understand the point of the 10% bonus for group land donations. How can a group own 10% more land than the original owners can donate if doing so bumps them up to a higher tier?

As I commented in SVC-7700, the problem of the float stopping when an avatar attemtps to sit on it while moving only seems to happen when there is an avatar already sitting and another one attempts to sit. A single avatar attempting to sit wiil cause the object to stop but then it reliably restarts once the avatar is sitting as described in the wiki. Since we always had multiple avatars already sitting, we always got the results I originally described.

So you're saying that "reset" as it's desceibed in the wiki means resetting the current path to its start position, and not "erase the current path" to [] as I had interpreted it to mean. As I remember the behavior, the float took off immediately to the right after the PLAY, instead of proceeding forward as ti would have if it were starting from the beginning.

I just used llSetKeyframedMotion to control floats in a Mardi Gras parade. It really did make programming the path A LOT easier over the LlSetLinkPrimitiveParamsFast way of doing it. It worked decently and fairly smoothly. I didn't bother to calculate times in multiples of 1/45 and didn't have any real issues. That path basically navigated one loop around a city block so minor changes to the path were not a problem. Although I didn't have any real problems with the vehicle getting nudged off path, the incremental way of moving the vehicle along got me to thinking that an absolute way of entering a series of postions would probably allow the vehicle to stay on path if nudged. See SVC-7475. Probably the biggest gotcha was the fact that any random avatar attiempting to sit on the float while it was moving caused the float to stop. The only way to get it moving again was for someone with edit privileges to go quickly in and out of edit mode. The wiki talks about the fact that selecting the moving object causes it to stop, but it was not obvious to me that sitting would also cause the same thing. I filed a JIRA on that SVC-7700. The other gotcha, was the fact that issuing a KFM_CMD_STOP did not seem to reset the object as described in the wiki. Issuing a KFM_CMD_PLAY right afterward (via a listen command) caused the float to start off on an unpredictable path. I would have thought that a PLAY after a STOP would do nothing. I filed SVC-7698 about that. Finally we got caught by the 64 PE limit of obejcts using this function. It wasn't clear to me at first in the wiki that they were talking about the PE of the whole linkset. There are actually 2 problems here. First is the totally weird way that PE is calculated. I you happen to use a single sculpty prim, it's PE gets doubled when you link it to the convex hull root prim. This makes no sense to me. The second is the 64 PE limit itself. I think that's rather limiting. I filed SVC-7699 about that. Since parade floats are pretty complex objects with lots of sculpty prims, we ran into to the 64 PE limit rather quickly. Luckily a friend of the builder came up with an ingenious work around. We had a "driver" sit on a pose ball linked to a simple base float in a static pose. We then had the avatar wear the top part of the float as an attachment. So we successfully had our parade with very elaborate floats. The only downside to this work around was if the driver would have crashed. Luckily this didn't happen and if it did we had alternate drivers who could quickly step in.

It actually worked quite well in lag. I bit jerky but still very acceptable

Thanks for the input. I'll give it a try and let you know how it goes.

I'm considering using llSetKeyframedMotion to move a parade float. I expect there will be quite a bit of lag. Can anyone comment on your experience using llSetKeyframedMotion in server lag sitiuations with significant time dilation?

Firestorm 3.2.2 (24336) Nov 27 2011 17:05:37 (Firestorm-Release) Release Notes You are at 286,899.0, 264,941.0, 61.2 in Sekmet located at sim9771.agni.lindenlab.com (216.82.45.105:13003) Second Life RC LeTigre 11.12.12.246583 Error fetching server release notes URL. CPU: Intel® Core i7 CPU 960 @ 3.20GHz (3207.31 MHz) Memory: 12280 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 480/PCI/SSE2 Windows Graphics Driver Version: 8.17.0012.8562 OpenGL Version: 4.2.0 RestrainedLove API: (disabled) libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Not Connected Settings mode: V3 Viewer Skin: starlight (original_teal) Font Used: Deja Vu (96) Draw distance : 128 Bandwidth : 2000 LOD factor : 4 Built with MSVC version 1600 Packets Lost: 0/76,352 (0.0%) Graphics set to High. I disable AA and AF in the viewer and have my video card override that natively. Lighting and shadows disabled. Looking out the window in my house at ground level, I get about 80 FPS. With Lighting and Shadows I get about 15 FPS. Jumping to my skypad at 3800, I get about 100 FPS without Lighting and Shadows.

I' eagerly looking forward to it. And I'm game to try it without the manual. BTW, IDK what you mean by "with particular settings on the skeleton". I hope that means I will be able to import my avatar's exported "new archetype.xml" file ... hint hint.