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

LSL Wiki : llRequestPermissions

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl427.us.archive.org
llRequestPermissions(key agent, integer perm)

Ask agent to allow the script to do perm, which can be any of the following constants joined together through bitwise OR (|).

Flag Value Result Allows
PERMISSION_DEBIT 2 Requests permission to take money from agent's account. use of llGiveMoney
PERMISSION_TAKE_CONTROLS 4 Request permission to take agent's controls. use of llTakeControls and llReleaseControls
PERMISSION_REMAP_CONTROLS 8 Requests permission to change keys for an agents controls may allow script to modify what the controls do
PERMISSION_TRIGGER_ANIMATION 16 Requests permission to trigger animation on agent. use of llStartAnimation and llStopAnimation
PERMISSION_ATTACH 32 Requests permission to attach/detach from agent. use of llAttachToAvatar and llDetachFromAvatar
PERMISSION_RELEASE_OWNERSHIP 64 ? <Deprecated> releases ownership of the object (The concept of public objects has been removed from SL.)
PERMISSION_CHANGE_LINKS 128 Requests permission to change links. use of llCreateLink, llBreakLink, and llBreakAllLinks
PERMISSION_CHANGE_JOINTS 256 ? <Not implemented yet> change the attachment's joint
PERMISSION_CHANGE_PERMISSIONS 512 ? <Not implemented yet> change permissions without use of llRequestPermissions
PERMISSION_TRACK_CAMERA 1024 Permission to track the agent's camera position and rotation Use of llGetCameraPos and llGetCameraRot
PERMISSION_CONTROL_CAMERA 2048 Permission to control the agent's camera position and rotation Use of llSetCameraParams and llClearCameraParams

Requests for the PERMISSION_DEBIT and PERMISSION_CHANGE_LINKS constants can only go to the object's owner. Requests for all other permissions can go to any agent.

Invokes the run_time_permissions event when agent accepts or rejects the requested permissions.

Be aware that the effects of this call are not additive. This means that all desired permissions must be requested for any call because the new permissions (or lack thereof) will completely replace the old permissions. Requesting permission FALSE (or 0) will result in all permissions being released and will not raise the run_time_permissions event handler. (This release functionality is currently broken! See: https://jira.secondlife.com/browse/SVC-1006 for more information.)

Further, multiple agents may not grant permissions to the same script at the same time. For an object to have permissions for multiple agents simultaneously, one script is needed for each agent. They may still be within the same prim, however.

Permissions are retained over script state changes, taking to inventory and re-rezzing, but are lost on a script reset.

As of 1.10.5.1, PERMISSION_CONTROL_CAMERA will not be granted in combination with either of PERMISSION_CHANGE_LINKS or PERMISSION_DEBIT even to scripts in attached or sat-upon objects, and the call will fail with a misleading error message.
Q: Is the fact that you can't combine PERMISSION_CONTROL_CAMERA and PERMISSION_CHANGE_LINKS together a bug or does it have a purpose?

Q: According to the official Linden scripting docs, llRequestPermissions should return an integer. What is returned? Is it the permissions granted, all of the now-available permissions, etc.? Is this integer passed to run_time_permissions?
A: No, this is an error in the official guide. It doesn't return an integer. Trying to capture it results in a compile error. My guess is that the help text is right and this function doesn't return anything.

Q: Looks like there is a max range for the perm request (looks like it always fails from sim to sim), what is it?
A: When requesting all permissions there isn't one (you don't even have to be in the sim but this might be limited to the owner).
A: Permissions for owner may be anywhere, permissions for non-owner agents are limited to the simulator, this is an anti-spam provision. - Ice

Q: If this call fails, because the avatar is offline, or otherwise unable to grant permissions, does it hang, or does it trigger run_time_permissions with the permissions shown as ungranted?
A: run_time_permissions is not triggered.

Q: When requesting permissions from an attachment, permissions are automatically granted if the script requesting them is in the root prim. However, if the script is in a child prim, the user will always see a permissions dialog. Is this supposed to happen or a bug?
A: This is presumably a bug. If you need a script in a child prim, and want the object to be quiet, place a corresponding script in your root prim to request permissions, then use link messages to communicate between the two. Alternately this is possibly intentional to prevent placing rouge scripts which take some sort of control in child prims where they may be hard to locate.
A: As of server 1.25, attachment child prims should automatically get permissions just like the root.

Compare with llGetPermissions and llGetPermissionsKey.

See control for an example.

See FutureRevisions to see the permission flags of the future.


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

Functions | Agent/Avatar
Comments [Hide comments/form]
No idea why I thought the bad camera/debit|links combo failed (i.e. set not-running) the requesting script. It doesn't.
-- SapatEngawa (2006-07-05 11:45:01)
llRequestPermissions(key, FALSE); does trigger the run_time_permissions event.

<pre>
key k_own;
default
{
state_entry()
{
k_own = llGetOwner();
}

touch_start(integer total_number)
{
llRequestPermissions(k_own, FALSE);
}

run_time_permissions(integer permission)
{
llOwnerSay("run_time_permissions triggered by llRequestPermission(key,FALSE)");
}
}
</pre>

DalarianDyrssen
-- p508e8764.dip0.t-ipconnect.de (2007-05-21 13:35:24)
Though it is technically possible to request PERMISSION_ATTACH from an avatar other than the object owner, it appears that (as of SL build 1.17) an object is never able to initiate the transfer of it's own ownership by attaching itself to someone who does not already own it. Therefore, requesting PERMISSION_ATTACH from a non-owner is possible, but absolutely and totally useless.
-- cpe-67-49-125-53.socal.res.rr.com (2007-06-24 13:26:31)
Attach a comment to this page: