sl-service-account
commented
1 year ago JIRAUSER341305 commented at 2023-09-20T05:14:12Z
You seem to have forgotten to mention how this prompt is actually made to the user? (Presumably that would be with a new command? It'd make sense if events could return a string to display as a message…) Is the sim supposed to just sit around if this is the 63rd event in the scripts queue, and every event before it contains an llSleep(3600)? What about every other script in the object, they should all receive an event like this! (Or maybe just the ones not being unlinked?) How to handle several all trying to notify the user with conflicting messages, or several of them supporting the event but ignoring it (for events returning a value, that'd mean returning a blank string). What if two people try to unlink the object at the same time (as in, a second person comes along between the first doing so, and actually responding to the message), or the same person twice — lag, possibly, the viewer can mostly stop that by blocking further actions. Unless it crashed — what to do if the user crashes out before responding to the prompt?
There's a limit of 256 prims in an object, so I'd have thought a list of link numbers would be a better parameter (either remaining or departing) — this affords the ability to check they're not unlinking some critical component of your object, vs. the extra 32 particle effect prims.
Worse case is about 4kb, but the upper limit is readily calculable, so we can work with it. (Unless there's any plans to increase that number, of course.) Personally, I'd probably prefer an integer bitmap, but that's likely getting a little complicated for some folk. (Besides, hopefully by the time we get more prims in an object, we've also already gotten the foreign event parameters not taking up script memory idea.)
Or, perhaps the solution is to allow scripts to Undo — during the resultant changed/_LINK event (and only during that specific event), the script can call an llUndoUnlink command to slurp the prims back in again. Maybe also lock the resultant objects for a short time (say, a couple seconds) until the event gets processed.
And lastly, a similar thing for linking would be a good idea. The number of times people link a house to their door script, and how the whole house spins around when someone tries to use the door — it'd be a chance for the script to let the user know it doesn't really support being linked to anything. (Could also be a good time to check if the two objects LSD stores will at least plausibly fit together — since no one sane actually wants remote LSD, which we'd need to check the inevitable name collisions.)
How would you like the feature to work?
This new event would be a complement to the built-in viewer notification that prompts users when they attempt to unlink a link set.
Syntax: before_unlink(key id, integer count, integer root)
Where:
root is a boolean parameter that is TRUE if the root object is selected for unlinking.
The event would be trigged in all objects in the link set.
Unlike the viewer notification, this event cannot be disabled in Preferences.
Why is this feature important to you? How would it benefit the community?
Accidental unlinking is a very common reason for a variety of frustrating user problems, including the inability to move objects together, scripted features ceasing to function, land impact changes, etc.
Additionally, many users do not know how to unlink a single object and instead unlink the entire link set. Because there is no undo function, this can force users to delete and re-rez objects. This can be problematic in the case of no-copy objects and/or very time consuming for large builds. Users may also disable the built-in notification.
Having an additional way of messaging users would allow creators to explain in detail what the effects of unlinking would be. The root and count parameters would allow the creator to tailor the messaging to reflect the possible consequences – or to display no additional warning.
The event would also be an opportunity to take any mitigating steps, if possible.
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-234436 | | Summary | New event: before_unlink() | | Type | New Feature Request | | Priority | Unset | | Status | Been Triaged | | Resolution | Triaged | | Reporter | Cain Maven (cain.maven) | | Created at | 2023-09-19T19:54:32Z | | Updated at | 2023-09-20T19:05:05Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-09-20T00:14:12.143-0500', 'How would you like the feature to work?': 'This new event would be a complement to the built-in viewer notification that prompts users when they attempt to unlink a link set.\r\n\r\nSyntax: before_unlink(key id, integer count, integer root)\r\n\r\nWhere:\r\n- id is the UUID of the agent attempting to unlink the link set in which the script resides.\r\n- count is the number of objects in the link set that have been selected for unlinking.\r\n- root is a boolean parameter that is TRUE if the root object is selected for unlinking.\r\n\r\n\r\nThe event would be trigged in all objects in the link set.\r\n\r\nUnlike the viewer notification, this event cannot be disabled in Preferences.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Accidental unlinking is a very common reason for a variety of frustrating user problems, including the inability to move objects together, scripted features ceasing to function, land impact changes, etc.\r\n\r\nAdditionally, many users do not know how to unlink a single object and instead unlink the entire link set. Because there is no undo function, this can force users to delete and re-rez objects. This can be problematic in the case of no-copy objects and/or very time consuming for large builds. Users may also disable the built-in notification.\r\n\r\nHaving an additional way of messaging users would allow creators to explain in detail what the effects of unlinking would be. The root and count parameters would allow the creator to tailor the messaging to reflect the possible consequences -- or to display no additional warning.\r\n\r\nThe event would also be an opportunity to take any mitigating steps, if possible.', } ```