automated deletion of scripts from large sets of prims

Hello

I am a scripting idiot still and need some help.

I do a lot of building using scripted prims that position themselves where I want them to be, and although I understand what the scripts are *doing* quite well, (I did not write them of course), but that is not the same thing as being at the level where I can re-write or alter them (yet).

Typically I end up with large (200-400 prim) structures, mostly in linked sets but sometimes not linked at all if it doesn't seem necessary.

My problems are:

1- an automated way to go through the prims and delete the old scripts, but only *specific* scripts not others.

2- a similar way to put things *into* the contents of the prims would be very handy as well

3- I need to be able to do the "blinds" thing where I can automate the changing of textures on selected surfaces of the same assemblages.

Two people have kindly helped me with the part 3 already but I am ashamed to say I have never got it to work propperly. I think I could though once I have a better understanding of operations 1 and 2.

I have a suspicion that this is impossible unless the prims are linked into a set but I dont really know. Even having a script that I could drop on a prim that deleted everything inside and then deleted itself would be an improvement over manually selecting 400 prims one by one. Being able to pick and chose what gets deleted would be better of course. Being able to set properties of the prims in the same manner (like "locked" for instance) would be heaven!

Lastly, although I see it's possible to specify prim faces for texture changes, there is nothign in the wiki that clearly shows what the syntax is for this. How does one refer to a particular side of a prim and know which face is actaully going to change? Presumably by number, but which number is which face on a given prim?

I have had the nasty experience of being talked down to a bit and patted on the head by some of the older men on topics like this so I would like to emphasise that I am *not* stupid, just scripting illiterate. Leave your chauvinism at home and I will be exuberantly thankful!

And if it's about monetary compensation, just let me know. I dont mind paying for help or reciprocating or whatever, I am more interesting in solving the problem than worrying about stuff like that.

.

Just about finished the SL end of an import/export tool, so I have been digging through a lot of these in the last few days. Almost to the point of being able to e-mail 90m radius collections of scripted and textured prims into and out of SL... (sleep is for the weak)



If you can get a running script into the prims (either by including it initially or through llRemoteLoadScriptPin) you can use llGetInventoryName and llRemoveInventory to filter things out. The script can then llRemoveInventory(llGetScriptName()) to remove itself. This requires the script pin of the targetted prims to be known.



llGiveInventory will let you transfer items from the current object into a target (by key), so a box with some scripting can move objects out fairly easily. An easy east way to find the keys of large numbers of objects is to use llSensor and check llDetectedOwner to identify your own. This requires nothing other than the ability to add contents to the targetted inventories (and some way to find the object keys). I am creating objects one at a time, and not modifying them later, so I dump the inventories in object_rez (which gives me the relevent key).



llSetTexture, llSetColor and llSetAlpha are the usual set to do this. They will either be in a script on the object waiting for a message, or delivered by llRemoteLoadScriptPin (giveInventory can not transfer running scripts). Just doing an llSetAlpha(0.2) when "open" and llSetAlpha(1.0) when "closed" would probably work for most private screens.



llSetStatus and llSetPrimitiveParams will allow you to control a fair number of the properties, though I do not believe any of them give you locked. Physics, phantom, shapes and sizes however are available.



The face numbers are described in a little more detail here in the Wiki. My experience is that the best bet is to walk through them and get a feeling for what will change: ALL_SIDES will do everything, and numbers 0-8 will either change one face or not apply to the specific object.

Can come up with more detail, or more specific examples if you need them (though trial and error plus the wiki will probably teach more ). I will not be in-world much until my stability problems get fixed, so am not much use for hands-on assistance (SL is now the only thing that does not run perfectly on my machine, unless I take out half my memory *grump*).

Dianne,

If at some point you start your build with a single prim, and that will be copied over & over, you could make one simple 'listen' script. This script would listen for a command over a private channel (please not channel 0) for a certain command shouted. So say the command was "DELETE|MYSCRIPT" it would recognize the DELETE command and kill any script inside of itself named MYSCRIPT. And then it could hear "DELETE|SELF" and kill itself when all done.

I have an automated window privacy script I can shoot you in world as well. You just shout '/101 privacy' to toggle it from pure black to a nice diamond window grid. Or if you forget to shout and only half the windows turn you can shout '/101 reset' and they all go back to original state. The window texture is referenced via it's key so you wouldnt need that in the prim's inventory.

And I'm not even gonna mess with loading items into a prim automatically lol. I know it can be done as outlined above, it just makes my brain turn to mush.

I wouldn't recommend this. 100 additional listeners will put a measurable amount of load on a simulator. Go for the llRemoteLoadScript solution, you can find more details about that on the wiki.
==Chris

Maybe it's just me, but I rather suspect 100 idle listeners are a better solution than waiting five minutes for llRemoteLoadScriptPin to do its thing (or rezzing more worker objects, and absolutely killing the sim and asset server).

Unless LL decided to implement the channel selection as an O(N) search or something equally stupid, I really don't see how the overhead can be as high as claimed. Even being near the sim boundary should not make a difference (a sane implementation would communicate the chat across sim boundaries rather than sending the listener field). Will have to find a quiet sim at some point and play with it...

Also remember that since the listeners are on a non public channel, they arent doing anything but sit there until something is communicated over that channel. I've had 300 listens open with no noticable effect on lag.

hey dianne,

I have a feeling reading this, you'd still have no idea what to do. Hard for scriptors to give non-scriptors advice sometimes. First of all, I wouldnt' bother much with with uptting things into an object with scripts using llRemoteLoadScriptPin() it requires a server to hold the key and PIN of each object then telling it which objects to send to and what to send and blah.

I wish there were an easier way to know which face was which, you'll get accustomed to which is which over time, but if you set a texture with 1-8 or so numbered on it and have a script get each face and print the correct number no each side you will be able to tell. Tihs would be required on each prim. I know, that sucks. There is a sample script ofr this somewhere in forums with the texture UUID included and everything.

As for deleting scripts, I'll give you an example of sometin I use a lot. I know you say you aren't at the pint of modifying given scripts yet, but you gotta start somewhere

default
{
    state_entry()
    {
        llOwnerSay((string)llGetLinkNumber());
        llRemoveInventory(llGetScriptName());
    }
}

Yes indeed! (to both)

I kind of figured as much.

I *do* use a single prim loaded with the scripts and overlayed with a texture that allowes me to be aware of the orientation and then res it over and over again to make the structure. So presumably I will only have to figure out which face is which one time only?

Basically we are talking about a whole lot of triangles, and I want to change the inside and outside faces with the "blinds" script, leaving the tiny edges with a third texture that never changes. I am thinking that once worked out, I only have to put this in my original prim, not figure out faces for each one after the fact?

Right now, I have "blinds" scripts loaded in the prim for when the structure is completed, and the scripts that tell it what to do during the assembly process. I need to figure out what dumb thing I am doing that stops the former from eventually working, and a method for the deletion that does not involve selecting 400 tiny tiny prims one after another. It takes hours and hours and gives me a sore wrist. I figure eight to ten mouse clicks a prim, times about 400. I have done this many times over too!

This code is more like a puzle than a solution, or perhaps a homework assignment, which is I think your point.

Well, I *am* at the point of modifying scripts already, and I have done some simple things, but I am not very good at it. I am more of a picture person with eidetic memory than I am a symbolic logic type, which is of course the whole problem really.

I appreciate your help, and thanks everyone for the comments above, (I did understand most of it) and I will do my best with my "homework."

I am starting to think that perhaps this is a bit beyond me for now but I will give it a shot.

.

Diane,

Sorry if I got too geeky there. As for the listen script I mentioned, simply put this in your base prim.

The inventory deleter:

default
{
   state_entry()
   {
      llListen(10,"",llGetOwner(),"");
    }
   listen(integer chan, string name, key id, string msg)
   {
      if(llToUpper(llGetSubString(msg,0,5))=="DELETE")
     {
         msg=llDeleteSubString(msg0,6);
         llRemoveInventory(msg);
     }
   }
}

Simply shout "/10 delete scriptname" where obviously scriptname is the name of the script you want deleted. I believe this will also work for this script too when you're completely done building.

Thanks Synergy.

And thanks to all who posted on this thing. I am sure I will get there eventually, I just have to digest all this stuff first.

.

It's an interesting point of debate. And it depends a lot on what you mean by lag as well as how loaded the sim is in which you're doing it.

It's well-established that listens do put load on the server, no matter what channel they're on, and regardless of whether they are doing anything. It shouldn't be that way, but it is. Hopefully, LL will re-implement this in a more efficient manner in the future. Certainly, the introduction of MONO will help a lot.

Not believing this, I did my own experiment a while back and I could see a steady drop in server FPS as I added listeners. It didn't contribute to lag because I was in a healthy sim with lots of room to spare. But I'm sure that it would contribute to lag if the sim were already borderline.

In general, it appears that any "active" script puts significant load on the server. While this doesn't necessarilly translate immediately into lag, it can.

I'm not saying that people shouldn't use them, but it's a fact that every listener is doing something even if it's doing nothing.