injection script

I've search along all the forum to find out a functional way to copy a script from the root prim to all child prims.
I still mind to create a resizer script for my creations (hairs).
i've take a look to http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSetScale and seems interesting.
The only problem is to copy all the child script in all the linked prims that could be more of 200 in my case.

An idea i still try to realize is:

create a child script
drop it into a root with a injection script and run it so all child script will copied to all child linekd prims.
drop in the root prim a Core script that listen all the child parameters and say in chat all the parameters so i can put into a notecard.

remove all child prims

make a config notecard with all child prims parameters.
i think that is possible now reading the notecard parameters to change the child scale without have a child script in it... (if i don't make a mistake).

someone can give me a good direction or help?

ty
Zer

Take a look at http://wiki.secondlife.com/wiki/Fix_Small_Prims for an example of how to propagate scripts from the root to all the children quickly and reasonably painlessly.

thank you so much i'll take a look

Zer

injection currently requires that the object go back to inventory before the child scripts will function after injection. that's the only real caveat, uses llGiveInventory by grabbing linked prims uuid.

however if you are only changing the child prims physical properties and don't need to know read them, llSetLinkPrimitiveParams should work fine, no injection needed.

you can bypass the take to inventory caveat if there are already scripts in your target prims by using remote load script prim, but it won't help for child prims that don't already have scripts.

That's the problem, though. In this particular example -- resizing the linkset -- you need to know the local position of each child prim so you can move it as well as resize it in order to keep the relative positions right.

Could you avoid injecting the script by using llGetObjectDetails() and and llGetLinkKey() to loop through the linkset to read the position and size of each object? I'm not sure you could because I think llGetObjectDetails() returns the sim position, which wouldn't be much help, would it? I don't know. I have made a resizer myself, using the method the OP is considering, though it didn't at the time occur to me to do it any other way.

It would be ever so convenient if we had llGetLinkPrimitiveParams().

assuming you compared the feedback to the objects root position I suppose. you can get around the limitation by memorizing the position/size of the children, but it's only stable if the object is no mod, s'only reason I mentioned the SetLink workaround... the added benefit would be the ability to reset if anything goes wonky, though it has limitations too

and yeah, ditto on the wanting getLink... the headaches that could be avoided.

sorry for answering so late but was away
The idea to make a resizer script for hairs (my products) is to sell no mod items and by a menu allow the resize.
My idea is to avoid to leave scripts in each prim but in some way read the original position and size and store it for example in anotecard in the root prim with the controller script.

i've tested some solution but probably i'm not a good scripter

Zer

You could always leave the object modifiable, and avoid the need for an annoying script.

lol is the way i use now

but i admit i-m interested in a script resize

Zer

What was wrong with the llGiveInventory() solution? Whether to leave scripts in there or to have them record prim properties and delete themselves, it should be a workable solution.

I agree that in this case llGiveInventory() should work for pre-existing prims. Void says you have to take it into Inventory to activate the scripts--which shouldn't be a show-stopper in this case--but (unless there's a bug I don't know about) Tools/Recompile and Tools/Set Running should work, too, without the step of taking it into Inventory.

Now, if the hair prims didn't yet exist, one could build them from prims that had llSetRemoteScriptAccessPin() called in them, and then llRemoteLoadScriptPin() would work. The script that sets that PIN doesn't have to remain in the prim for it to still work.

Couple of things about this whole scheme, however. First, llSetLinkPrimitiveParams() is throttled to 0.2sec per call, so with 200 prims in the linkset, that's 40 secs to do one resize operation (assuming just one calling script in the root prim). Also... do people really use scripted resize for hair, of all things? I can't imagine that having acceptable results on humanoid avatars, like *at* *all*. It hardly ever works for shoes, even, and avatar heads are dramatically varied in shape; I've never owned prim hair that I didn't have to adjust, prim-by-prim, or I looked as if I just got off the short bus.

Qie makes a very good point about the need to adjust hair prim by prim.

Now I come to think of it, when I adjust prim hair I'm not so often resizing the whole linkset as moving or rotating one or two prims in order to keep their bases hidden inside my head.

last I heard recompile/reset was bugged, but I haven't been keeping up lately

works for me, except i use it in the reverse, set it running, and then recompile

Flame here!

The way I see it here, you have three methods:
1) Insert a script into every prim manually (doable, but annoying).
2) Work with llSetRemoteScriptAccessPin and llRemoteLoadScriptPin (doable, but I am pretty sure it's a more long version of number 1)
3) Get the child primitives to allow inventory dropping (llAllowInventoryDrop possibly?), then have the root simply go through all the link prims (llGiveInventory(llGetLinkKey(linknum),"Script name here"). While I am VERY positive this is alot like number 1 (since we need to get all the child primitives to allow the inventory drop), this would be my more practical choice (because then once you are done, you can pop a script that makes the child primitives to not allow the inventory drop when done).

I'm pretty sure that all of these solutions have already been mentioned, but hopefully an explanation from another view would help fill in any gaps.

if you have mod perms of the object, you don't need to allow inventory drop, whether you use allow inventory or not, giving a script with llgive inventory always has it not running. but if you try to give a script to a no mod object that has allow inventory drop, it won't let you*

*unless it's given via llgiveinventory or it's in a folder that you drop into the object, both cases it's not running and can't be set to running

I'm pretty sure they fixed it in time for Mono. Recompiling all scripts in an object to Mono definitely works now, but potentially takes a very long time even on low-load sims (I HATE Mono compile times, but they're server-side,so what can you expect?).