Don't click here unless you want to be banned.

LSL Wiki : llRemoteLoadScriptPin

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl805.us.archive.org
llRemoteLoadScriptPin(key target, string name, integer pin, integer running, integer start_param)

In SL 1.12 a serious bug was introduced in this function, causing the bytecode to be stripped from the source code and loaded as a seperate, unnamed inventory object that would be named "Old Script". Any scripts that used llRemoteLoadScriptPin() between the deployment of 1.12 on 8/23/2006 to the rolling restart on Friday 8/25/2006 created these... problems. llGetScriptName() is unable to differentiate between the different scripts as they're ALL named "Old Script", and any inventory functions will only work on the first instance in inventory. Future update scripts will need to be written to look for these "Old Scripts" and their uncompiled properly named source stubs and handle them accordingly. -DragonEccleston

If the owner of the object containing this script can modify the object identified by the key target, and if the pin matches the PIN previously set using llSetRemoteScriptAccessPin (on the target prim), then the script name will be copied into target.

If the target prim already contains a script with the same name as name, it will be replaced without any warning.

Notes:
* target must be a different prim than the one containing this script. llRemoteLoadScriptPin cannot copy a script into itself. Also, target must identify a rezzed prim, existing in the world. It cannot be in the inventory of an object.
* It might not have gotten clear from the above statement: The owner of the prim containing THIS statement must have modify rights on the OTHER object. Also see the remark below about handing out a helper prim.

If running is TRUE, start the copied script with start_param. start_param can be retrieved using llGetStartParameter in the copied script's state_entry.

Note: this function delays the script for 3 seconds.

Example:
llRemoteLoadScriptPin(targetID, scriptName, pin, TRUE, param);

Note: llRemoteLoadScriptPin only works if both prims are in the same sim.

If copying fails, (for instance, if key == llGetKey()) the script will shout (yes, really!) "Unable to add item!" on channel 0. It makes three attempts (check this out--and then what?).

If an incorrect pin is used, the script sends the following error to the DEBUG_CHANNEL: "Object: Task Object trying to illegally load script onto task Other_Object!"

This function replaces the deprecated llRemoteLoadScript.

See llGetScriptState and llResetOtherScript for other fun things you can do with this.

If you need to update scripts for your end users, consider putting the updated scripts inside of an object which is then delivered directly to end users via llGiveInventory. This object, if rezzed in the same sim as the item being updated, can then negotiate a PIN with the object and the scripts can be updated/enabled automatically.
-- DirtyMcLean


See llGetLinkKey to get the key of a child prim. This works, at least as of 1.13.2.11. --DunselHodgson

Loading the current script into another prim works as of 1.13.2.11. --DunselHodgson


Example:
//This example will be of two linked prims 
default
{
    touch_start(integer total_number)
        {
            llGiveInventory(llGetLinkKey(2),"foo"); 
            llRemoteLoadScriptPin(llGetLinkKey(2),"foo",165,TRUE,0);
        }
}
//What this is does is send the script "foo" and the  'pin' 165 to prim 2 and set the script running when touched.
//the receiver script ~/HAS/~ to be in the other prim before you touch it otherwise it will say illegal transfer

// The receiver script will have 
default
{
    state_entry()
        {
            llSetRemoteScriptAccessPin(165);
        }
}


This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Functions | Inventory
Comments [Hide comments/form]
Any reason why both objects need to be in the same region? It makes it hard to do worldwide updates.
-- HankRamos (2004-09-03 17:47:26)
Interestingly, it doesn't throw an error when the target prim has been deleted.
-- SeifertSurface (2005-11-19 22:03:01)
It seems you have to either own the target object or have been granted rights to modify the owner's stuff by the owner in order for this to work. It's not enough to have the PIN. But if you already have these rights, is there a point to the PIN?
-- LavanyaHartnell (2006-03-11 11:05:03)
Extra precaution. Would really mess things up if a hacker got into your object. Adding a PIN isn't that hard so why not?
-- HazVega (2006-04-05 03:08:14)
Right, extra precaution. The pin was added so that a seemingly-harmless object given to you by a griefer can't start loading scripts into everything around it owned by you when you rez it in-world.

The pin does add some ugliness to it all, I agree. I wish llSetRemoteScriptAccessPin worked on all the prims in a link set :-/
-- ChristopherOmega (2006-04-05 15:23:53)
If you are here because you are looking for advice on updating scripts for your end users, consider putting the updated scripts inside of an object which is then delivered directly to end users via llGiveInventory. This object, if rezzed in the same sim as the item being updated, can then negotiate a PIN with the object and the scripts can be updated/enabled automatically.
-- DirtyMcLean (2006-06-19 21:30:29)
Attach a comment to this page: