This repository has been archived by the owner on Feb 28, 2024. It is now read-only.
[BUG-20065] Feature Request: llFreezeAgent() - A scripted means of freezing an agent with both moderation and recreational uses. #2762
Labels
Information
Please do not triage for two weeks, until July 12th or later. Give people time to comment. Thanks.
Currently we have eject, ban & freeze ability with the viewer but of those, we only have eject and ban by script.
There have been many times when I preferred my security system would freeze an agent when they are in violation of certain rules so they can be given an opportunity to read a dialog explaining the issue along with an agreement button instead of ejecting or banning them.
While an agent is in frozen status, they cannot move or chat, their objects/attachments cannot use scripted rez functions and their script's touch events are halted.
Aside from traditional moderation use, this functionality actually has great potential for recreational use in scripted form.
This feature request is for the following function:
integer llFreezeAgent(key agent, integer seconds, string message)
agent - agent to be frozen. Must be in the same region as the script.
seconds - amount of time in seconds agent is to be frozen. Operation is similar to llAddToLandBanList() where time can be extended with values that increase the end time and values that don't are ignored except that 0 now thaws the target and negatives subtract seconds from frozen end time.
message - message sent to agent as a toast. If null string, no message is sent.
Returns 0 if failed, returns 1 if successful.
The script calling the function must be owned by the land owner or deeded to the land group the same as required with llEjectFromLand()& llAddToLandBanList() or alternatively, operate from an experience compiled script targeting someone in the same experience over land that has the experience allowed similar to the improvement request for llUnsit().
Benefits
Scripted freezing can be incorporated into security system designs as alternatives to eject/ban where appropriate.
Experience based apps can freeze participants in games or RP environments that have waiting periods, timeouts or penalties.
Other Information
At the moment the time limit for freezes via the viewer is a set 30 seconds, but with scripted use the limit could be anything from 1 to 3600 seconds or even more so all use cases can be satisfied.
The llGetObjectDetails() constant OBJECT_FREEZE_END_TIME will be needed to monitor if an agent is frozen or not and/or when their freeze time ends. This is preferred over an llGetAgentInfo() constant which only uses bitwise values.
https://jira.secondlife.com/browse/SVC-2491 will also have to be addressed.
Comments welcome. Thanks in advance for any consideration.
Original Jira Fields
The text was updated successfully, but these errors were encountered: