Skip to content
lsl.devlsl.devLSL Dev

llRequestPermissions

function
Function syntax
llRequestPermissions(
  1. key agent,// UUID of the agent in the same region.
  2. integer permissions// Bitfield containing the PERMISSION_* constants to request. Values: ScriptPermission
);
Energy
10

Ask agent for permissions to run certain classes of functions.

Script execution continues without waiting for a response. When a response is given, a run_time_permissions event is put in the event queue.

How to use
llRequestPermissions(NULL_KEY, 0);
ConstantsActionCategoryGranterAutomatically granted when…
PERMISSION_DEBIT0x2take money from agent’s accountMoneyOwner
PERMISSION_TAKE_CONTROLS0x4take agent’s controlsControlAnyonesat on, attached
PERMISSION_TRIGGER_ANIMATION0x10start or stop Animations on agentAnimationAnyonesat on, attached
PERMISSION_ATTACH0x20attach/detach from agentAttachmentOwner or Anyoneattached
PERMISSION_CHANGE_LINKS0x80change linksLinkOwner
PERMISSION_TRACK_CAMERA0x400track the agent’s camera position and rotationCameraAnyonesat on, attached
PERMISSION_CONTROL_CAMERA0x800control the agent’s camera
(must be sat on or attached; automatically revoked on stand or detach)
CameraAnyonesat on, attached
PERMISSION_TELEPORT0x1000teleport the agentTeleportAnyone1
PERMISSION_SILENT_ESTATE_MANAGEMENT0x4000manage estate access without notifying the owner of changesEstateOwner
PERMISSION_OVERRIDE_ANIMATIONS0x8000configure the overriding of default animations on agentAnimationAnyoneattached
PERMISSION_RETURN_OBJECTS0x10000Used by llReturnObjectsByOwner and llReturnObjectsByID to return objects from parcelsCleanupOwner, Group Owner
PERMISSION_PRIVILEGED_LAND_ACCESS0x80000Grants the script privileged access to land parcel functions, such as parcel sale. Used by llSetParcelForSale.LandOwner
PERMISSION_GAME_CONTROL0x100000Permission to receive game_control input events.ControlAnyonesat on, attached
  • A dialog is presented to the agent to grant these permissions except when granted automatically as shown in the table above.

  • If object is attached to agent, “automatic” permissions are granted without notification upon request.

  • Permissions persist across state changes.

  • Regardless of whether granting is automatic, you should always use the run_time_permissions event. Granting permissions takes time, and you shouldn’t assume it’s completed until the run_time_permissions handler gets invoked.

  • The menu-option “Stop Animating Me” will release certain permissions (PERMISSION_TRIGGER_ANIMATION and PERMISSION_OVERRIDE_ANIMATIONS), if the script which holds these permissions is in the same region as the agent, and the script is not attached to the permission granter.

  • Permissions do not accumulate.

    • If a permission was requested with a previous call to this function and granted, then in subsequent call was not requested, that permission is released (lost).

    • To request two or more permissions at the same time, use the bitwise OR (|) operator, e.g.:

      llRequestPermissions(AvatarID, PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION)
  • Permissions are requested and granted separately for each script, even if they are located in the same object.

  • It is currently not possible to request no permissions at all (see Issues below); as a workaround llResetScript can be used.

  • Scripts may hold permissions for only one agent at a time. To hold permissions for multiple agents you must use more than one script.

  • The result of granting permissions affects the return of llGetPermissions and llGetPermissionsKey immediately, despite the run_time_permissions event being queued, or dropped if the object’s event queue is full.

  • Permission request dialogs never time out.

  • If a script makes two permission requests, whichever response is last is considered the granted permissions.

  • The viewer limits permission requests from any agent to any other agent to 5 dialogs in 10 seconds.

  • Permission requests and changing state …

    • Requesting a permission in one state, then changing state before the agent response, will cause run_time_permissions to be fired in the new state once the agent responds.
    • Requesting only auto-granted permissions in one state, then immediately changing state, will never fire run_time_permissions.
Request permission to animate an avatar
default
{
touch_start(integer detected)
{
llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
}
run_time_permissions(integer perm)
14 collapsed lines
{
if (perm & PERMISSION_TRIGGER_ANIMATION)
{
llStartAnimation("sit");
llOwnerSay("animation will end in 5 seconds");
llSetTimerEvent(5.0);
}
}
timer()
{
llSetTimerEvent(0.0);
llStopAnimation("sit");
}
}
To request two (or more) permissions at the same time, use the bitwise OR (|) operator.
llRequestPermissions(AvatarID, PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION);
: - or -
integer perms = PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION;
llRequestPermissions(AvatarID, perms);

When an agent grants a script non-automatic permissions they will receive a notification (in chat) of

  • The name of the object that contains the script that has been granted perms,
  • The name of the owner of the object,
  • The location of the object in the order Region name at position, and
  • A statement of what permissions were granted.

If the script that holds the permissions is in a child prim the name will be that of the child prim (not the object (root)) and position will be its local position (relative to its root).

From the issue templates included by the wiki article:

  • SVC-1006 (bug): Unable to release script permissions
  • SVC-8067 (nf): Improved Permissions Handling
Original wiki source

Some wiki templates and tables need their original context. View this article on the Second Life Wiki. Technical wording and examples are retained from the source; historical guidance may differ from current behavior.

  1. PERMISSION_TELEPORT cannot be held by temporary attachments. ↩