Madi Melodious With all due respect, I don't think you read all that I wrote above. I will address your worries for you, but I still encourage you to re-read all the above. (1) Unsuspecting people can already have their camera taken control of, animated, be orbited over region borders so fast they are logged out, spammed etc all by wearing an attachment from their inventory that is auto-granted permissions. (2) Under age players are unable to enter adult regions regardless of the method used. (3) Permissions requests were not added because of the things you mentioned, they were added because of a bug in temp attachments that has since been resolved. (4) Experience is unable to operate outside of experience enabled land, so a teleport HUD for example would be useless if it needed to rely on an experience. (5) As a scripted content creator from 2006 I am well aware all of these issues, and none of them are mitigated by retaining a popup permission that was meant to be retired over a decade ago. See my other posts for the history of why it was added. I suspect it was before your time.

SuchieGirl Resident That is an interesting suggestion, and I like it because it would also deal with the other permission issues people have previously complained about.

The only issue I see here is that a viewer revoking a permission that a script has already been auto-granted - it will result in existing scripts attempting to do things without permissions, normally resulting in the script SHOUTING an error message in local chat. eg: ....

Normal flow for a script is:

(1) request permission

(2) Wait for the permission to be granted (by viewer or automatically by region)

(3) use function requiring the permission.

However if the viewer can revoke the permission it will likely happen between steps 2 and 3 when the user presses NO to the permissions dialog box. User input will never be faster than auto-granting so it will break auto-granted permissions.

I don't think it would be worth creating a dedicated on/off for just one teleport permission, and doing other permissions too will break too much content. Not to mention the backlash creators will have to deal with when customers think their products are faulty after turning off the viewers auto-granting option.

Darling Brody They could put an, "Are you sure you want to turn this off? It could cause other scripts to not function properly..." warning. i just am not really fond of the idea of removing it completely. Sometimes you accidentally grant permission for something you did not mean to because you were clicking something else. At least as it is still an option, if you TP, you get a chance to deny it. However, there are HUDs that i have used that ask once to auto TP and never have to ask again. i am not sure if it works the same or what process they used, but i can take them off and put them back on and the perms are still saved.

SuchieGirl Resident those huds that ask once use a dedicated script that is never reset to hold the permission. Something I mentioned as an undesirable option due to using resources unnecessary.

Woolfyy Resident There is an experience based teleport function already - I used it to create the grid wide Quantum Portal Network - and there is the non-experience based teleport that works from your own attachments but it requires a permissions dialog box to be displayed to the resident first.

That permissions dialog was added over a decades ago, after teleport was combined with temp-attachments to teleport people without their permission.

The issue was actually with temp attachments, but with everyone being teleported all over SL against their will LL locked the teleport permission because it was presumably the faster solution. Later the temp-attach permissions were fixed, but the teleport permission remained at the higher level that is causing customers to complain.

In my experience (pun intended) getting people to join an experience or group is difficult. The process is complicated for new people and the experience joining dialog is often buggy where it doesn't register someone selecting join. Add to that it wont work outside of land with the experience enabled and it is pointless for a teleport function in hud, as it can't be used everywhere.

Darling Brody Aren't those tp for RP i'e usually for people also from a predefined group?

Woolfyy Resident One product of mine has a list of people in the region and it can teleport you to one of those people if you click on their name. It also has a bunch of other teleport related quality of life enhancements. It is not part of roleplay, rather it is just to make it easier to use SL.

Linking functionality to joining a group will be problematic for people with no group space. Imagine if every product did that, our profiles would be full of company group names instead of our interests.

The experience system fills the "group with permissions" functionality but it has serious limitations as it only works if your over land with that experience enabled. I have a number of products like Quantum Portals and Stargates that make use of experience's teleport abilities and I have run into the issue of land owners and their visitors not having the experience enabled. It is just another thing people need to learn which makes SL more complex to play. In the case of an in-world object teleporting someone, experience (one enabled) is a seamless way to integrate functionality for land owners.

Now, we have a teleport command intended to work from attachments without any other limitations other than an annoying permissions request. A permissions request that was added hastily during a griefer attack to fix an issue. An issue that was resolved by blocking the ability of a temp attachment from using the teleport command at all. Thus the need for the permissions popup is no longer required.