Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-2467] Feature Request: llGetAttachedList() - Land Owner/Deeded LSL function to return all root keys of an agent's attachments if over owner's land. #11832

Closed
sl-service-account opened this issue Apr 30, 2013 · 0 comments

Comments

@sl-service-account
Copy link

User Story

As a moderator for many sandbox regions I have on many occasions had to ask guests with excessive script memory or timing to reduce their usage. There are many difficulties that can be involved with this, primarily not being able to visually find which of their attachments is using the most resources or what body part it is attached to. So I'm left with telling them I can't find the attachment thats the cause or that it may be an HUD or ask them to check all their attachments to lower their usage without being able to tell them what to check or detach. In many cases, they aren't familiar with what scripts are or how high levels can impact region stability.

I propose a land owner/deeded based LSL function that can return all the root keys of an agent's attachments if they are over the same owned land.
This list can be correlated with llGetObjectDetail's OBJECT_NAME,OBJECT_ATTACHED_POINT and/or OBJECT_SCRIPT_MEMORY,OBJECT_SCRIPT_TIME constants so a moderator can easily see what attachment(s) are using the most resources and simply tell them to check or detach the attachment by name and/or the point its attached as well as reference that attachment's memory/timing usage in contrast to their total memory/timing usage.

Other information

Related to SVC-3560 but this request is restricted to both land owner/deeded usage as well as restricted to agents that are over the owner's land. This request also is based on a more legitimate use case than that proposed in SVC-3560.

Original Jira Fields
Field Value
Issue BUG-2467
Summary Feature Request: llGetAttachedList() - Land Owner/Deeded LSL function to return all root keys of an agent's attachments if over owner's land.
Type Bug
Priority Unset
Status Closed
Resolution Not Applicable
Reporter Lucia Nightfire (lucia.nightfire)
Created at 2013-04-30T17:19:33Z
Updated at 2015-07-14T23:36:24Z
{
  'Business Unit': ['Platform'],
  "Is there anything you'd like to add?": "Related to SVC-3560 but this request is restricted to both land owner/deeded usage as well as restricted to agents that are over the owner's land. This request also is based on a more legitimate use case than that proposed in SVC-3560.",
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': "As a moderator for many sandbox regions I have on many occasions had to ask guests with excessive script memory or timing to reduce their usage. There are many difficulties that can be involved with this, primarily not being able to visually find which of their attachments is using the most resources or what body part it is attached to. So I'm left with telling them I can't find the attachment thats the cause or that it may be an HUD or ask them to check all their attachments to lower their usage without being able to tell them what to check or detach. In many cases, they aren't familiar with what scripts are or how high levels can impact region stability.\r\n\r\nI propose a land owner/deeded based LSL function that can return all the root keys of an agent's attachments if they are over the same owned land.\r\nThis list can be correlated with llGetObjectDetail's OBJECT_NAME,OBJECT_ATTACHED_POINT and/or OBJECT_SCRIPT_MEMORY,OBJECT_SCRIPT_TIME constants so a moderator can easily see what attachment(s) are using the most resources and simply tell them to check or detach the attachment by name and/or the point its attached as well as reference that attachment's memory/timing usage in contrast to their total memory/timing usage.",
  'What were you doing when it happened?': 'test',
  'What were you expecting to happen instead?': 'test',
}
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant