Q re rezzing coalesced sets via script

[Monica Balut]

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?

 

[Rolig Loon]

Coalesced objects are not linked, so that explains why most of the things you want to do won't work as planned.  When you create a coalesced object, you are simply picking up a bunch of unlinked objects at the same time. They will rez in the same relative positions that they had when you picked them up, but they will behave like the unlinked objects that they are.  That's why people are generally advised to be sure to open the Build/Edit window before they rez a coalesced object.  If you do that, the objects, although not linked, can still be manipulated simultaneously.  When you rez a coalesced object with llRezAtRoot, however, you don't have that option. 

What you are trying to create is a rez box, like Builder's Buddy or Rez Faux.  There are several on the market.  They typically contain your coalesced object plus a keystone object of some kind that behaves as an anchor point for all the individual parts of the coalesced object.  You record the positions and rotations of those parts relative to the keystone object, which then acts like a root prim of a linkset.  When you move it, its script makes all the loose pieces follow and stay in their relative positions and rotations.

I have used a variation of the method you describe for handling small objects (doors, swings, ... ) that cannot be linked to a larger structure but need to rez together and then be moveable.  For example, I'll have a simple script in a swingset  frame that looks for a rezzed swing nearby and then tells it to move to the right position on the frame so that the whole unit is complete. If the owner moves the frame, a moving_end event activates the script momentarily to reposition the swing on it.

[Monica Balut]

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.

 

[Rolig Loon]

Here's a very simple alignment script, activated bt touch rather than by moving_end (which I agree can be flaky).....

integer gDialog;default{    touch_start(integer total_number)    {        if (llGetOwner() == llDetectedKey(0))        {            integer DCHAN = (-1) * ((integer)llFrand(100000) + 1);            gDialog = llListen(DCHAN,"","","");            llDialog(llDetectedKey(0),"Click \"OK\" to align swing parts", ["OK"],DCHAN);        }    }        listen (integer channel, string name, key id, string msg)    {        llListenRemove(gDialog);        llSensor("Smooth Swing","",SCRIPTED | ACTIVE | PASSIVE,10.0,PI);    }        no_sensor()    {        llOwnerSay("I can't find the swing. Please be sure that it is within 10m of this frame.");    }        sensor ( integer num)    {        vector SwingPos = llDetectedPos(0);        rotation SwingRot = llDetectedRot(0);        llSetRot(llEuler2Rot(<0.0,90.0,-67.5>*DEG_TO_RAD)*SwingRot);        llSetPos(SwingPos + <0.00,-0.03,0.665>*llGetRot());    }}

 

[Miranda Umino]

By experience :

with non-physical prims , use llSetRegionPos and not llSetPos to trigger moving_start and moving end events .

Even with a velocity of ZERO_VECTOR , it works . Nevertheless, you ll get only the final position  when you check llGetPos() inside moving_start and moving_end events .

So in fact , it useless to catch the two  both events moving_start and moving_end  at the same time , if you use llSetRegionPos

 If you call several llSetRegionPos in the same current event ( for instance you several llSetRegionPos in a timer event , touch_end event ) , only the last llSteregionPos will be triggered

 

vector shift = <0, 0, 1.0>; default{    state_entry()    {        llSetTimerEvent(2.0);           }    timer()    {        shift = -shift;        llSetRegionPos(llGetPos() + shift);    }    moving_start()    {        llOwnerSay(llList2CSV( [ "moving_start", "shift", shift, "pos", llGetPos() ]));    }    moving_end()    {        llOwnerSay(llList2CSV( [ "moving_end", "shift", shift, "pos", llGetPos() ]));    }}

 

[Monica Balut]

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.

[Qie Niangao]

---

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.

---

Interesting.  So, a coalesced object, when rezzed, generates multiple object_rez events, one for each linkset in the coalesced object?

[Monica Balut]

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.

[Alicia Sautereau]

Just use Builders Buddy, it`s free, opensource and pretty great as a diy tool

https://marketplace.secondlife.com/p/GNU-Builders-Buddy/3041232

No idea wich version that is and i think the last is 1.10

[Miranda Umino]

 

Interesting.  So, a coalesced object, when rezzed, generates multiple object_rez events, one for each linkset in the coalesced object?

 

Yes . But if you use it take care about the 64 events limits in the queue : your coalesced object can easily have got more 64 linksets objects . And you ll miss some object_rez events

[Monica Balut]

Thanks for pointing that out Qie