Help with sending a texture to a prim...

I create a prim and in its contents I added a few textures and added another prim. I create a script that does something simple like randomly pick one of the textures on a touch then rez the prim with the texture. The problem I am having is how to apply the texture to the prim in the contents without also putting a script into that prim and use the link message functions. Is there a method to do this?

TIA
Ren

See . I posted an answer when you asked the same question in the Buiilding Tips forum.

to add to what Rolig is saying, the only way to get a texture onto an unlinked prim that's being rezzed is to have a script in it, or for it to already be there... and that's a key concept... if you stick several prims in inventory, with the textures already applied, when you get your touch, you just pick which prim to rez...

A more complicate solution would be....
on_touch -> rez a prim with no texture.

//setup communication between the parent obj and the new child obj
ie. in the child (in on_rez) setup a listen on a channel based on it's key, in the parent (in object_rez) do the same.

Also in the parent (in object_rez) use llSay,llRegionSay, etc. to send the key of the texture you want the child be textured with.

In the child (in listen() ) snag that texture key and texture self

Slightly less complicated would be to just have the child listen to the parent based on parent's object name...then in the listen event...

Since the OP wants to have a random texture applied to the rezzed prim at the time of rezzing, I like Void's suggestion, which would look something like this ....

default
{
touch_start(num_detected)
{
llRezObject(llGetInventoryName(INVENTORY_OBJECT,((integer)llFrand(llGetInventoryNumber(INVENTORY_OBJECT)-1))),llGetPos() + < 0,0,2 >, ZERO_VECTOR,ZERO_ROTATION,1);
}
}

Then all the OP has to do is texture a whole mess of prims and drop them in his parent object along with this script. It's even simpler than the script I suggested, and you only have to put it in one prim.

Welp...ok. I mean I dunno...multiple copys of the same object (except for texture) hanging around in the contents folder seems a little messy to me. Why not have just one child object listening to the master to tell it what texture to use?

Trick is how to texture the child after it has been rezzed. Personally, i would go with passing the child just a texture UUID (using the communicatiing) scheme. No need to worry about inventory changes, updates to texures, and which version of the child object is in the master's contents...etc. Just a listen script in a single child object, that applies whatever texture (via UUID) it is told to use from the master.

Nope. You missed the point of Void's note. I suggested a simple way to apply a texture randomly during the on_rez event, and she pointed out that it would be much easier to simply store pre-textured prims and rez them randomly. That way, you don't have to place a script of any kind in the child prim. You don't even have to mess with texturing. One script, a collection of pre-textured child prims, and you're home free.

Hehe...I dont miss points on prgramming.
Anyway...I've used the communcation technique above many times and it's rock solid. Been used in missiles, scanner probes, drop pods, etc.. It IS just very messy having effectively the same object lingering in the contents folder. bottom-line

Yup. I've used that method a lot myself. It's very handy if you need to make changes to a child after it's rezzed and free in the world. In this case, however, the OP doesn't want to keep changing textures after the child is rezzed. He just wants prims that have a random texture each time you rez a new one. So there's no need to communicate with the child once the deed is done. Keep it simple .....

My first solution was to apply the texture to a naked child as it was being rezzed. Void's alternative was to rez child prims that are already textured. It's six of one, half a dozen of the other. In one case, you have to write two scripts (one for the parent and once for the child) and in the other, you need one script and a flock of child prims. Neither one is difficult, but Void's solution is attractive because there's never more than one script running. There's no overhead involved in storing a bunch of child prims in the parent -- they're only pointers to the asset server, after all -- so it looks to me as if Void's solution wins, hands down.

Oh totally...Void's solution would certainly work. It's a fast (yet i have to say "dirty" method to get it done But ya know...maybe that's the way for the OP to go.

But what IF the OPs question is just the first in a long string of questions as he builds whatever he is ultimately building (this does happen)? What if his system will grow later to include things like someway to automatically delete a particular object-thingy-ma-bob?

For me..I would much rather pay for a little programming time overhead, but know that later if a system grows it is ready to be expanded upon.

~Az

Then he has a nice, short collection of alternatives to choose from in this thread, and so does anyone else who reads it. Nothing wrong with that.

my solution ignored the communications to fill the requirement of having no script in the rezzed prim (alternatively you could have the com script, and just delete it when the task was finished)... I think the no script solution was a requirement of the way the device operated, so that users could drop in their own prims (of course it does leave a question of how to get the texture on their initially... odds are the user is going to need to fool with a script sooner or later)

Then for completeness here's a link to the answer I posted to the same question in building tips

/8/c9/329159/1.html#post2490409

I think that does cover all points of the query, including texturing a non scripted prim