how to move groups of object (together)

[Marcin Pang]

Hi,

I do not know how to move groups of objects. I will describe porblem:
In the first room I rezzed a few objects (patients), sending information about the number of objects (their position, etc.) to another room. From the second room comes conveyor (mobile bed) and move the objects into the third room. Conveyors are rezzed as needed

I do not know how to combine objects with conveyor (move patients along with the bed). I wanted to link them, but it requires permission from agent.

Ps. I hope I described it clearly...

[Lee Ponzu]

One possible approach.

When the conveyer arrives at the patient, it sends a message to the patient.  The patient then "follows" the conveyer.  That is, the patient uses the same movement algorithm the conveyer uses so they both appear to move together.

Lots of detail left out 8-)

ponzu

[Rolig Loon]

If you don't need to keep taking the patient on and off of different beds, one solution is to just have the patient "sit" on the bed once and then move it from one place to another.  If necessary, you could trigger different animations in each new place without unseating the patient.  If you go to a bit of trouble, you can even make the bed transparent occasionally so that the patient appears to be separated from it (kinda tricky to script, but doable in theory).

[Marcin Pang]

How can i make patient follows the conveyer ? Could you give an example ?

This is the code, which I'm using to move the bed (yes... it's non-physical object...) : 

  

go(vector position){       vector last;    vector new;    vector krok = (position - llGetPos())/100;    do {        last = llGetPos();        new = last + krok;        llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,new]);        llSleep(0.1);    } while ((llVecDist(llGetPos(),position) > 0.1) && (llGetPos() != last));}

 

 

Ps. I was thinking about transparent bed, but it is felt to be somehow odd...

[Qie Niangao]

---

Marcin Pang wrote:

Ps. I was thinking about transparent bed, but it is felt to be somehow odd...

---

"Odd" or not, that's how I think I'd approach the problem: single-prim "proto-conveyors" that are always persistent (so they retain PERMISSION_CHANGE_LINKS) and that rez the rest of a bed around them and link to that assembly, then move to the rezzed "patient" objects and link to those, too, so the combined bed+patient assembly can move around as a single linkset.

The "patient" and "bed" prim assemblies would need to be unlinked when you're done with them, and be (or become) scripted to know when they should llDie().

[Marcin Pang]

I should understand that it is impossible to link the patient to the bed (without asking for permission), or make the patient to follow the bed (like Lee said)?

[Qie Niangao]

The script that calls llCreateLink() needs to get PERMISSION_CHANGE_LINKS from the owner, yes.  The script should do that right away.  They don't have to ask permission again later as long as the script doesn't reset, release permissions, or ask for different permissions.  That's why I suggested the always-present "proto-conveyors" -- if they don't go away, they don't need to get permission again.

The other restrictions -- that both objects be modifiable and have the same owner -- would not seem to be a problem (although it constrains what permissions under which you could transfer the whole thing).

The annoying part is getting rid of the linked-to prims.  You can delink them all at once or one at a time, but either way I think you'll need to have a script inside each of them to make them llDie()... and that's a lot of (very simple) scripts.

It's not so clear to me, however, why the "patients" and "beds" need to be rezzed dynamically.  That operation will fail unless there are enough unused prims available on the parcel, so you'll ultimately need the same number of prims anyway.  If, instead of all this linking (or following), you can have them all rezzed from the start and merely manipulate the transparency of some prims, it would be less scripting and less lag.

[EDIT TO ADD:  I've understood from the first post that the "patients" are objects, not avatars.  If instead the patients are avatars, that's a completely different problem, which was the direction Rolig was taking: then the patients would have to sit on the beds.]

[Marcin Pang]

Why dynamically ? I wanted to make the simulator. From the notecard, loading data of patients. Then I make that patients and I carry out the simulation.

Ps. Yeah, patients are objects. I think it's pretty obvious (from the context).

[Rolig Loon]

---

Marcin Pang wrote:

 

Ps. Yeah, patients are objects. I think it's pretty obvious (from the context).

---

Oh.  That part didn't make sense to me as I read it, so I assumed it was an error.  Most patients I know of in RL are people.  :smileytongue:  If they are objects, that does change the whole system that I was envisioning. I still think that transparency is the way to go.  With this new understanding, though, I wonder why it's necessary ever to have the patients unlinked from the beds.  They are never going to be walking, talking avatars anyway.  Why not build they as permanent parts of a linkset that includes a bed that sometimes goes invisible?  When you're all done, make the entire linkset die, including the patient.  Then rez a new one and start over.  That way you never have to mess with linking and unlinking.