Monica Balut

Resident
  • Content count

    76
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Monica Balut

  • Rank
    Advanced Member
  1. Thanks for pointing that out Qie
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. It actually worked quite well in lag. I bit jerky but still very acceptable
  15. Thanks for the input. I'll give it a try and let you know how it goes.