Journey Bunny
Background and Motivation:
LSL provides llCreateLink, llBreakLink, and llBreakAllLinks for scripted linking and unlinking of objects. Before any of these may be called, the script must hold PERMISSION_CHANGE_LINKS, obtained by calling llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS).
This causes a dialog to pop up at runtime, asking the owner of the object whether to allow it to link and unlink things. Only the owner can grant this permission, and it must be requested and granted each time the script resets. This model is correct for its original purpose: a script inside one object is trying to reach out and attach itself to any other object in the world. The permission answers the question:
"Do you, the owner, allow this specific script, right now, to perform linking operations?"
The Analogous Script Pin System:
Second Life already includes a beautifully designed precedent for pre-authorizing cross-object operations: the llSetRemoteScriptAccessPin / llRemoteLoadScriptPin system. A creator places a script inside a target prim that calls llSetRemoteScriptAccessPin(pin). A calling script then passes that same pin to llRemoteLoadScriptPin to inject scripts into the target — no runtime dialog, no owner prompt. The permission was established
ahead of time
, by someone who had modify rights to the prim, when they placed the pin-setting script inside it. The pin is the credential, and possessing it is the grant.
The key insight:
A link pin system would allow objects to be 'set up to accept linking' in the same way that script pins allow objects to 'set up to accept remote script loading'. The hard permission work is done at configuration time by someone with mod rights, not at runtime by an owner who may not be present.
The Problem This Solves
• It requires the owner to be present and attentive when the script runs, even if they already "authorized" the behavior by crafting the product.
• It makes fully-automated, physics-driven, or time-triggered linking impractical in products where the owner is not online.
• It introduces UX friction that discourages creative use of a powerful simulation feature.
• It is conceptually mismatched to the scenario where both objects were built by the same creator specifically to work together.
The linking permission was designed for
open-ended scenarios
: a script that might try to link anything to itself. The proposed link pin is for
closed scenarios
: specific objects that have been explicitly configured to participate in a linking relationship.
Backwards Compatibility
Placing a link pin requires mod rights. Objects with mod rights can already be linked/unlinked without scripting. Link pins do not elevate capability — they only reduce the runtime friction for capability the creator already possesses.
The new functions are additive. Existing calls to llCreateLink, llBreakLink, and llBreakAllLinks are completely unchanged. Scripts that currently request PERMISSION_CHANGE_LINKS via the dialog continue to work exactly as before. No existing behavior changes.
Objects without a link pin set cannot be linked or unlinked by the new pin-based functions. An object that was never given a pin is invisible to the new mechanism.
Spec
• The pin is a 32-bit integer. Creators should treat it as a private shared secret between the orchestrating script and the pin-holding object.
• A pin of 0 means "no pin set" (cleared state). Setting a pin of 0 removes any existing pin.
• Both objects must still be owned by the same person. The pin bypasses the dialog, not the ownership requirement.
• A prim's pin persists across link and unlink operations (same persistence model as llSetRemoteScriptAccessPin).
• A creator can change or clear a pin at any time from within the object by calling llSetLinkPin again.
llSetLinkPin(integer link_number, integer pin)
Attempts to link the calling object to target, using pin as the authorization credential in place of a runtime permission dialog. The target's root prim must have a matching link pin set (via llSetLinkPin). Both objects must have the same owner and both must be modifiable. If the pin does not match, or the target has no pin set, the call fails silently (no error is shouted).
llCreateLinkPin(key target, integer parent, integer pin)
Attempts to link the calling object to target, using pin as the authorization credential in place of a runtime permission dialog. The target's root prim must have a matching link pin set (via llSetLinkPin). Both objects must have the same owner and both must be modifiable. If the pin does not match, or the target has no pin set, the call fails silently (no error is shouted).
llBreakLinkPin(integer link_number, integer pin)
Breaks the link of a prim identified by link_number from the current linkset, using pin as the authorization credential. The targeted child prim must have a matching pin set. This is called from the root/parent prim's script, not from the child being removed.