Open sl-service-account opened 8 months ago
sl-service-account
commented
8 months ago Lucia Nightfire commented at 2023-10-26T12:04:08Z, updated at 2023-10-26T12:06:11Z
Why not just another non-auto-granted permission at the script level?
PERMISSION_FRIEND_LIST_ACCESS
Then operation could be updated to work outside of same-owner-object as there are some legit use cases there as well.
sl-service-account
commented
8 months ago SparkleSpice commented at 2023-10-26T15:06:45Z
There surely are some use cases, but for some others I would think that could come into existance would be 'weapons' shooting friendly fire bullets.
Then there's the other half of the exchange, one person might agree to an object checking friends, the other person getting checked might not. I still think separating the permissions to a friends level (similar to how the pre-existing five flags work)
In anycase this needs to be thought out properly, with all implications considered before the function gets imlpemented.
sl-service-account
commented
8 months ago JIRAUSER341305 commented at 2023-10-29T16:33:01Z, updated at 2023-10-30T01:27:02Z
I'm not sure what this helps. Most people are probably just going to leave it on the default, if they're even aware what it does. If that default is "nope", then every single thing that wants to use the feature is going to have to beg and bug the users to tediously go through their friends list and enable it for every friend who may happen to play any associated game with them, and if you forget a friend, the feature is broken. With your double option suggestion, you presumably both have to manually enable it for it to work. For that reason alone, this is most likely dead on arrival.
Then, anyone who cares enough to use your feature, is going to want more granular control. The idea of "allow any script to see if I'm on it's owners friends list" still seems way too nebulous to be useful — it's at best a half-measure between global yes and no. And LL aren't likely to let every script ask every one of your friends if they mind, and then remember all those responses — nor would I want the inevitable resultant permission request spam. And that wouldn't really work anyhow, could you imagine 20 peoples guns all asking you if it's okay if they can see your friends list in the midst of combat?!?
Having it be an experience permission seems like the only real viable option here, to me. And even better, it could be restricted to only those friends who are also participants of the same experience. Though you know it'll just be standard in every experience, and the whole idea goes up in smoke again.
Honestly, llSameGroup (optionally with OBJECT_GROUP_TAG) seems to me to already do this job just fine. As it is, this whole llIsFriend thing seems a woeful pointless waste of effort, and generally bad idea, except possibly for toy radar hud's that want to put up a different coloured dot like the viewers do.
sl-service-account
commented
8 months ago Spidey Linden commented at 2023-11-01T17:47:17Z
Issue accepted. We have no estimate when it may be implemented. Please see future release notes for this fix.
How would you like the feature to work?
Whilst I can say wholeheartedly this function would be a useful and valid boon to content creators, as it currently stands it simply has too many gray areas for ill use.
I've mocked up an example of how I would personally change the script's functionality (which would be disabled by default.)
By implementing a new checkbox specifically for this function/similar functionality in the future, the end user of basically any product can fine tune exactly which friends they consent to have accessible via script call. Which I feel would be extremly intuitive to both old and new users alike.
EDIT:
After giving it slightly more thought, it might be useful to add two checkboxes instead of just one.
"My objects can see this friend"
Or at least something like this. It would line up with what currently exists in terms of friend permissons.
Why is this feature important to you? How would it benefit the community?
This would limit the amount of information that could be visible/gained from scripts created by third parties. It would prevent almost all foul play from anyone intending to use this for nefarious reasons.
An example of how it could be abused: Somebody has an experience for a region, the experience could be required to get around to specific places or attach HUD's / animate etc. This experience could then attach something compiled with this script function and immediately know who the user's friends are. (At least from the ones that are online at the same location) and make note of it.
Attachments
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-234596 | | Summary | Modify the soon to be implemented llIsFriend() before it gets released. | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | SparkleSpice (sparklespice) | | Created at | 2023-10-26T06:12:10Z | | Updated at | 2023-11-29T00:18:15Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-10-26T07:04:08.314-0500', 'How would you like the feature to work?': "Whilst I can say wholeheartedly this function would be a useful and valid boon to content creators, as it currently stands it simply has too many gray areas for ill use. \r\n\r\nI've mocked up an example of how I would personally change the script's functionality (which would be disabled by default.)\r\n\r\nBy implementing a new checkbox specifically for this function/similar functionality in the future, the end user of basically any product can fine tune exactly which friends they consent to have accessible via script call. Which I feel would be extremly intuitive to both old and new users alike.", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "This would limit the amount of information that could be visible/gained from scripts created by third parties.\r\nIt would prevent almost all foul play from anyone intending to use this for nefarious reasons.\r\n\r\nAn example of how it could be abused: Somebody has an experience for a region, the experience could be required to get around to specific places or attach HUD's / animate etc. This experience could then attach something compiled with this script function and immediately know who the user's friends are. (At least from the ones that are online at the same location) and make note of it.", } ```