what the best way to spawn scripted objects?

I was wondering what was the best way to have one script spawn another scripted object. And have the spawned object communicate with the spawning object.

I thought maybe there was a way to pass information to an object when it's spawn. I also relies I could use a listen and says on an invisable channel to have the two object communicate. And a timer to keep the sending object sending data. But is there a better way?

What the best way to detect if the spawned object has already been spawned, and what the best way for the spawn object to self-destruct. ie figure out the master object is gone, that the spawned object was left behind in a teleport, or the user logs out, extra.

Rez, not "spawn"!

llRezObject lets you pass an integer to the NEW object's on_rez event.

llRezObject also triggers the object_rez event in the original object.

Note that if you use the llRezObject/on_rez integer method, you'll have to hardcode all the available data. This is acceptable if you simply want to change between several finite states, but if you want to pass more complex, variable data like a name, key, or vector, you'll likely want to use chat.

There are a few techniques available for facilitating communication between spawner and spawnee:

- encode the information into the 4-byte param that gets passed to the spawned object.

For example, if you want to pass an x,y,z pos, you could encode it as:

param = (integer)x * 1000000 + (integer)y * 1000 + (integer)z;

- generate a random private channel number. Pass it in as the param to the new object. Anything sent on that channel will only be heard by you and the object

- if you're going to rez several objects at a time, you might want to combine the last two ideas: generate a reference number for each rezed object and multiplex it with the channel number. Say you want to rez 8 pawns, and your random channel number is 128534, then you could pass the following param to each pawn:

pawn n: 128534 * 10 + n where n is integer from 1 to 8

When the rezed object starts up (state_entry fires), it sends a "NEEDINPUT-=-" + (string)iReference request to the parent on channel 128534. The parent knows its a pawn (from the object name in the listen event), and knows which pawn it is (from iReference), and can send it the appropriate information.

- there's also an object_rez event, but if you're going to have communicaiton between spawnee and spawner anyway it doesnt add too much value. The event does tell you the key of a rezed object, but unfortunately theres no easy way of correlating this information with the objects thatyou've been rezing. Arguably it could be useful for preventing man-in-the-middle attacks.

One thing, voice of experience: if you're going to implement something that monitors if somethig is rezed or not and rerezes it if its not, make sure that the rezer and the rezee are two different objects, ie object A rezes object B. If you ever have a situation where object A rezes object A, it's *very* easy to accidentally get exponential self-replication, which is generally embarrassing.

Azelda

If all of your rezzed objects need to listen to the same chanel, the object_rez event would be your best choice.

You rez three of the same object, all 3 listening to the same command channel.

The object_rez event is called for each obect, passing in its key id.

llShout on the command channel with the key as a command parameter.

The object with that key is the only one that will obey the comand. The others will ignore it.


If they don't all have to be on the same command channel, passing in an indexed channel number in the llRezObject param value is the way to go. Just be sure that the same channel key remains available in the calling script to talk to each object as the object_rez event is triggered for each.


Oh, and If I make an object (A) and script it to rez a copy of itself from inventory, take a copy of (A) into my inventory, then put a copy of it into (A)... When it runs, the first (A) will create the second, but the second will break because it doesn't have an (A) in ITS inventory.

It will only go as recursive as you hand-stuff beforehand.

> Oh, and If I make an object (A) and script it to rez a copy of itself from inventory, take a copy of (A) into my inventory, then put a copy of it into (A)... When it runs, the first (A) will create the second, but the second will break because it doesn't have an (A) in ITS inventory.

> It will only go as recursive as you hand-stuff beforehand.

Oh, well what you do is:
- create object A
- add the script
- take a copy into inventory
- rez
- add A into contents

This will recurse quite happily.

It's true that if the contained A doesnt contain A, then things are safe but then your contained A is not really A, so you can call it B, and then you know it's safe.

Azelda

Thanks guys and gals. I'm happy to know I am on the right path. Even if I feel random is a messy solution. I guess i'll just have to chose a large range for the random number. Hopefully even if two object were spawned by different object, but had the same random number. One object would sink up, and the other would sink with the other. That or self terminate and start over.

I do find the idea of passing the position of the master object as a random number. I can't imagine two master object being in the same position. But I'm not sure if that really offer any more protection then a random number.

btw efficiency wise. Is there, any major advantage to sending data as a set vs sending each peace of data as a separate line? I would think a set of data would be more efficient and thus faster. But I would also think, a set of data would be harder to script. And be more complicated to process. So even if there was a slight gain in sending speed. The speed gain could be, and probable would be, lost in the process of converting the complex data string of data back into it's separate values.

Is there any gain in speed having one script do as much of the work as it can Vs trying to load balance the work? ie: sending the value to be set vs passing raw values, process those values and then setting those values.

You have a prim called "Object" with a script in it to rez an object called "Object" from it's inventory. We shall call this (A).

You take a copy of it into your inventory, then drag it into the original. We will call that one (B) since it s now different from the original (A) because (A) has (B) in it and (B) has nothing but a script. Let's rename (A) to (A-B) since it has a (B) in it.

So we have (A-B) with a (B) inside it. If you activate the script, you get one copy of a (B) rezed, and that's it.

Now we can take a copy of (A-B), and stick THAT inside itself. Delete the (B) from its contents. Rename the original (A-AB) since it has an (AB) in it.

Activate the script and you get one (A-B) which rezzes (B) and that's it.

You have to keep stuffing to keep rezzing. There is no way to put a copy of an object inside itself, because doing so changes it, but not the copy you are putting inside.

The system is safe from infinite recursion. (But not from people who choose to spend 6 hours stuffing and re-stuffing to get 1,000 nested levels that all rez 1,000 copies each!)

> btw efficiency wise. Is there, any major advantage to sending data as a set vs sending each peace of data as a separate line? I would think a set of data would be more efficient and thus faster. But I would also think, a set of data would be harder to script. And be more complicated to process. So even if there was a slight gain in sending speed. The speed gain could be, and probable would be, lost in the process of converting the complex data string of data back into it's separate values.

Parsing is pretty fast. Do this:

sMessageToSend = "MYCOMMAND-=-" + (string)vSomeVector + "-=-" + (string)fSomeFloat;

To parse it, do this:

list arguments = llParseString2List( sReceivedMessage, ["-=-"],[] );
string sCommand = llList2String( arguments, 0 );
vector vSomeVector = (vector)llList2String( arguments, 1 );
float fSomeFloat = (float)llList2String( arguments, 0 );

> Is there any gain in speed having one script do as much of the work as it can Vs trying to load balance the work? ie: sending the value to be set vs passing raw values, process those values and then setting those values.

Splitting the work across multiple scripts generally results in faster execution. I think that each script executes at a certain fixed rate, independent of sim load, so the more scripts the faster. How this is actually implimented I dont know the details, but it's an impression I've formed.

That said, the actual execution time is generally pretty fast compared with the cost of sending data across a shout connection and so on. Personally, I'd send the values that provide the most stable, intuitive public interface between the scripts.

Azelda