llRequestPermissions

llRequestPermissions( key agent, integer permissions );

Ask agent for permissions to run certain classes of functions.

• key	agent	–	avatar UUID that is in the same region
• integer	permissions	–	Permission mask (bitfield containing the permissions to request).

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

Constants		Action	Category	Granter	Automatically granted when…
PERMISSION_DEBIT	0x2	take money from agent’s account	Money	Owner
PERMISSION_TAKE_CONTROLS	0x4	take agent’s controls	Control	Anyone	sat on, attached
PERMISSION_TRIGGER_ANIMATION	0x10	start or stop Animations on agent	Animation	Anyone	sat on, attached
PERMISSION_ATTACH	0x20	attach/detach from agent	Attachment	Owner or Anyone	attached
PERMISSION_CHANGE_LINKS	0x80	change links	Link	Owner
PERMISSION_TRACK_CAMERA	0x400	track the agent’s camera position and rotation	Camera	Anyone	sat on, attached
PERMISSION_CONTROL_CAMERA	0x800	control the agent’s camera (must be sat on or attached; automatically revoked on stand or detach)	Camera	Anyone	sat on, attached
PERMISSION_TELEPORT	0x1000	teleport the agent	Teleport	Anyone^[1]
PERMISSION_SILENT_ESTATE_MANAGEMENT	0x4000	manage estate access without notifying the owner of changes	Estate	Owner
PERMISSION_OVERRIDE_ANIMATIONS	0x8000	configure the overriding of default animations on agent	Animation	Anyone	attached
PERMISSION_RETURN_OBJECTS	0x10000	Used by llReturnObjectsByOwner and llReturnObjectsByID to return objects from parcels	Cleanup	Owner, Group Owner

Caveats

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.

Credit to LSL Portal with changes for brevity and clarity.