Rez and move new prim

Hi, all. I'm a fairly seasoned programmer, but I'm new to LSL (and Second Life in general). I'm trying to get my feet wet at the moment, and I'm sure this question has been answered in the wiki or on the forums, but I wasn't able to find it with any of the searches I did.

Basically, I'm trying to create an object that will have some sort of parameters fed into it (let's say via chat). Using the information in there, it would rez some new prims and move them to a specific location, and it would also take some of the prims it's previously rezzed and move them to new locations as well.

Now, I know how to use llSetPos( ) to cause an object to move itself. I also see that, when I rez an object, I get a key for that object as the return code. What I'm curious about is whether or not there's a way to use that key to then move the rezzed object later.

The short version-- is it possible in LSL to code an object that can move other objects it's rezzed? If so, what is the method for doing this?

Again, I know that's probably quite basic, but I've been scratching my head digging through the LSL Wiki and forums.

Really, unless they are linked (as in one linkset object), one prim cannot Directly control another.

There's really only 2 main ways you could move the prims indirectly.

For an unlinked prim, you could relay the desired action via E-mail or chat from the control prim and have the prim scripted to receive these messages and then react appropriately using either physical (llApplyImpulse/llMoveTo) or non-physical (llSetPos) movement. For multiple prims, E-mail would not be recommended as it would be a lot slower than chat, as well as require each prim to constantly be polling for new e-mails.

or - this is a lot more complicated and not recommended...

Use the physics engine and have the control prim push the object to the desired position. This would require a lot of work and tweaking, especially if you wanted to do this to multiple objects.


The specifics would really depend on what you need as the end result. If it's a relatively few prims needing to move, then you could just have each prim listen on its own chat channel for instructions, or you could encode the messages so that the prims will be able to decode them and know if they should move or not. Also, if it's just specific points that they need to rotate through, you could have each know it's places in a list of preset points, and just have a simple "Next" command that they all know to move to the next point in the list.

Thanks for the information. I'd wondered about making my own protocol through chat channels but had thought perhaps there was better direct API support.

Now, let's say that I linked them. I've read that once you link two prims they become treated as a single object, so wouldn't this just result in moving the entire linkset around? I don't mind linking them because I haven't seen a compelling reason not to. Ultimately, this is going to be used for a data visualization tool, something akin to a map or globe with markers being created, destroyed, and moved on its surface to represent different events. I understand how to use the HTTP request system to draw in the data, but I'm trying to make sure I get the whole process of creating, moving, and destroying markers done correctly.

Have I got the idea about linking objects backwards, or is this a scenario where they should not be linked.

Hi and welcome Ivo

In a linked set, the rezzed objects that are linked to the parent(root) become 'children', with llSetPos called from within a child prim, its movement is relative to the root. Therefore the individual prim will move and not the whole object.

Using a linked set for your project has many advantages, faster communication - llMessageLinked, less laggy - no need to use llListen for communication with possibly many objects.

The main constraint to using a linked set is the physical size of your project and the distance limit on linking objects, if you can work within those constraints I see no reason not to favour using a linked set.

I use llMessageLinked in a region scanner, I use ordered lists to store rezzed prims keys, names, positions and an integer value to indicate if it is to be linked, de-linked (to die), or to move.

I have also seen one done that works via chat communication and unlinked prims/markers. I have to say that it seemed to operate with comparable script usage times with llListen as mine did with llMessageLinked, so with tightly filtered listens lag generation may not be a big issue...however, I am no expert on measuring this

Saskia,

Thank you for giving me some idea about the differences in the inter-prim communication processes. This is invaluable to me. Given that I'm looking at something like a map with dynamic markers, linking the prims seems to make a lot of sense. I'd read elsewhere that there was no guarantee of message delivery with llMessageLinked( ). Is this true? I can handle baking in robustness, but I figured I'd ask.

No problem Ivo



I have heard this too. I have not directly experienced it fail myself, and I use it as a preferred method of inter-object communication where-ever I can. I guess though that like anything in SL, there are no guarantees anything will work 100% of the time.

You can guarantee quite reasonably that you'll have 99.99% success. The only time you would have to worry is when you start getting near the throttle level, which is something like 64 messages a second or faster, if I recall..