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

LSL Wiki : llRemoteLoadScriptPin

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl338.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
There are 6 comments on this page. [Display comments/form]