llSetRemoteScriptAccessPin sets for prim only?!

llSetRemoteScriptAccessPin sets the pin just for the PRIM? Not for the whole object and all its prims?

OK let me explain why this is retarded. Why? Because the whole point of llRemoteLoadScriptPin is so that you can have a script do the dirty work FOR YOU.

Understandably, the pin must be set for security purposes. However for this to be required for each and every prim in a multiprim object is just ridiculous and takes it too far. Why? Because now you have to DRAG & DROP a script to set the pin into EVERY prim, which defeats the purpose of having the ability to avoid having to DRAG & DROP whatever script you're trying to distribute into each prim!!!

Case in point: I needed to make a script that would copy another script (that sets prim transparency) into every prim in a very complex object. The script that it copies into each prim allows people to make their guns or lightsabers appear/disappear. It is a script that is given to the user, that they then place in their newly-created object. Currently I have to use llGiveInventory() to distribute the script within the object, but then all the scripts start out as NOT running, so then the user has to set scripts to running (which is currenlty broken in the client -- you have to take it into inventory and THEN rez it and THEN set scripts to running or else the copied scripts from llGiveInventory() will NOT run).

This would be SO MUCH EASIER if llSetRemoteScriptAccessPin worked like it should and set the pin for all the prims in the object, thus allowing llRemoteLoadScriptPin to distribute RUNNING scripts within every prim of the object without the user having to manually place pin-setting scripts in each prim (which, if they are going to do that, then they might as well just be placing the transparency script in each prim, because that's all the llRemoteLoadScriptPin was going to be used to do anyway).

So OK, the llSetRemoteScriptAccessPin sets it just for the root prim but not all the other prims. Therefore you must copy a script into each individual prim BY HAND that will set the pin for each prim, WHICH DEFEATS THE WHOLE POINT of not having to copy the script into each prim by hand.

Does anyone see my point? Can Lindens PLEASE make llSetRemoteScriptAccessPin set the pin for all the child prims as well as the parent, pretty please? It would make life so much easier.

- Gistya

PS -- Sorry I was very tired when I wrote this, and it's a complex issue. Sorry if it's worded poorly I just want Lindens to fix this. Thanks.

PPS -- Proposal 3103, go vote ty.

llSetLinkAlpha not do the job a lot cleaner and without the need for one script per prim?

^^What Nand said Pretty much - have one prim be the 'control' prim, and have it do all the work on all the other prims. Then you only need to manage one prim PIN

LOL No you cannot just use SetLinkAlpha. It is not that simple. Why? Because every litesaber has a blade which, when you turn on the saber, becomes visible. Those prims which become visible have their own specific alpha's which are not 1.0 and are user-configurable. Also the blur prim stays invisible until you swing the saber. So if the script that hides/shows the saber when it is drawn says something basic like llSetLinkAlpha(LINK_SET,1.0,ALL_SIDES) then it will basically ruin the saber prims' proper alpha. Also because it is a LiteSaber Construction Kit, there is no way to know beforehand what the link numbers will be of the parts which are to have specific alphas, nor what those specific alphas are because the scripts which manage those specific alphas are inside those prims not in the main script. Further for the effect to be smooth of the saber turning on instantly it is necessary the each prim have the script which manages transparency so that when the link message is issued they all receive it at the same time and all turn on/off at the same time, rather than with a for loop in the main script which would make them appear in a particular order and would not look right.

Further, every hilt is different. A lot of people make saber hilts with partially transparent prims in them. And there is no llGetLinkAlpha command! The script that goes into each prim, it detects the alpha of each face and then records that, so that when the Draw command is issued, it can preserve the designer's original design of transparency rather than have it be simply set to 1.0 by a violent and overly simplistic llSetLinkAlpha command from the root prim.

I'm happy to post the code so you can see what I'm talking about if you want.

- Gistya

I have to agree that creating any kind of Set command without a corresponding Get command is rather shortsighted.

Sounds like for your application you could use a function like lSetLinkedRemoteScriptAccessPin. (longest LSL function name?)

Yes that would be excellent.

As you have to loop through a list of prims anyway (since, by definition, llRemoteLoadScriptPin can't be broadcast), why not use the newly-added llSetLinkPrimitiveParams?

PS if it was just in one prim there would be no point to using a pin! Since it would not be copying its script into anywhere!

The whole point of using RemoteLoadScriptPin would be to efficiently copy the script into the other prims without having to do it by hand. But because you have to load a script by hand to set the pin, it defeats the purpose.

Gosh!

-=GE=-

PPS -- This is proposal 3103, go vote if you agree. Then maybe the Lindens will take notice. Thanks.

I think you're attributing intentions other than those of the developers to this function. There are already numerous existing functions allowing linked prims to communicate with each other, without needing to shuffle scripts around between them, and two more were just added.

I've used llRemoteLoadScriptPin as a "messenger" of sorts to communicate dynamic integer data between unlinked and widely separated prims without use of chat channels, listeners and intermediate relays, but it probably wasn't originally intended for that purpose, either.