Grid-wide experiences

[Lavanya Hartnell]

Is it possible to create an experience that works grid-wide? Or will these only work on regions or parcels that allow the experience?

For example, a system of grid-wide teleporter HUDs, where user interaction with each HUD triggers llTeleportAgent(). My current design requires the user to grant TP (and attach) permissions once for each HUD they get. It would be nice for them to grant the experience once and have it apply to every HUD using the same software.

[Innula Zenovka]

No, the owner of the parcel (rather than the whole region necessarily) needs to allow the experience before it works on that parcel.

However, I'm a bit confused by your description.  If the HUD needs permission to attach, it's presumably being rezzed by a scripted object.   If that's the case, then why can't the person who chose to place your HUD rezzer on the parcel (the owner, or someone authorised to rez thing objects there, at least) allow your experience to run on the parcel?  

Once the HUD is attached, it can simply request PERMISSION_TELEPORT in the normal way, and have it silently granted since the wearer is the owner.    The only time you need to worry about experience permissions that I can see in this scenario is when the HUD wants to attach, and since the parcel owner wants people to be able to rez your HUD there from from the object she's just placed, presumably she won't mind allowing the necessary experience to run there.

Or am I missing something obvious?

Edited April 27, 2017 by Innula Zenovka

[Berksey]

Um, I'm pretty sure experiences are region-specific (allowing for error on my part), and in terms of the other part of your question, I'm pretty sure there are several ways to have attached objects talk to people in other locations (via IM, for example), but getting them to talk to other objects tends to be (in my experience) limited to objects within the same region...

I see someone more qualified just replied while I was typing this, so I want to read what she says about it now...

EDIT: Yeah, what she said.

Edited April 27, 2017 by Berksey

[Lavanya Hartnell]

I should clarify. This is a HUD that is given out. It could be that you gave a copy to your friend. So there is no telling what sim someone will be on when they wear the HUD. Now, I don't need attach permission for them to manually attach it, but I do seem to need the permission to detach it for them if they hit a "close" button or once they complete a teleport. That's really annoying and I don't know why it's required, but I haven't figured a way around it.

As for the teleport permission, again, the HUD could be worn at any point in time and on any sim.

Okay, so if this was just one HUD, this would be no problem, but it's not. This is a free service where anyone can create their own "dynamic landmarks". Each DLM comes with its own branded HUD, so if one person has 20 DLMs to different clubs, shops, etc., they have to grant the same permissions at least 20 times. Here's the product:

    https://marketplace.secondlife.com/p/My-dynamic-landmarks/11534763

That's where it currently stands. First time you wear one of these HUDs, you have to grant permissions to teleport and attach (detach) before continuing.

See why granting an experience to all of these HUDs one time would be valuable? They all use the same scripts from me, so they all have the same security considerations. But I don't think it's practical to engage in a campaign to convince all region owners to add my experience just for this minor product.

Thoughts?

Edited April 27, 2017 by Lavanya Hartnell

[Rolig Loon]

I see what you're dealing with, but Innula has given you the answer.  PERMISSION_TELEPORT is granted automatically to the wearer of an attachment, so although you do have to request permission, the wearer should not  be faced with having to grant it explicitly.  The only thing to watch out for (if you look at the footnote in the wiki entry for llRequestPermissions) is that a temporary attachment cannot simply ask you one time for permission. It has to request permission new each time.  And yes, you do still need to have PERMISSION_ATTACH before the wearer can detach the HUD.  That can be a little tricky when you're working with temporary attachments, but look at the examples in the wiki entry for llAttachToAvatarTemp. They show you how to do the necessary extra step of re-requesting permission after you attach the HUD.

Edited April 27, 2017 by Rolig Loon
Typos. What else?

[Lavanya Hartnell]

Thank you for the follow-up. I checked the documentation for llRequestPermissions(). Sadly, PERMISSION_TELEPORT  is not automatically granted to the wearer of an attachment the way, say, PERMISSION_TRACK_CAMERA is. However, you do explain well why I still have to request PERMISSION_ATTACH to detach the HUD, even if the user would not normally see a visible request. I hadn't realized this aspect of permissioning prior.

In any case, the basic answer is: no, you can't design an experience to work grid-wide. Noted. Thank you all for your replies. Too bad, though.

[Rolig Loon]

1 hour ago, Lavanya Hartnell said:

[ .... ]I checked the documentation for llRequestPermissions(). Sadly, PERMISSION_TELEPORT  is not automatically granted to the wearer of an attachment the way, say, PERMISSION_TRACK_CAMERA is. [ .... ]

Do a quick experiment to double check what the wiki says, because I'm pretty sure it's wrong.  I'd check myself, except that I am out of town and can't log in to SL successfully on motel wifi.  I made myself a personal teleporter a couple of years ago, and I really don't think I have to grant permission explicitly.

[Lavanya Hartnell]

My software already demonstrates this, though. The HUD is worn. Upon the first rezing (when worn), the script detects that it does not yet have permission to teleport the owner, so it requests permission. This causes the usual permission dialog to show, as seen in the included image. Note how it visibly asks for permission to both attach and to teleport.

I thought maybe there was a difference between permissions during the on_rez() event and the attach() event that could account for this behavior, but I don't think it's that. If the user chooses "No", the script again asks the user for permission. This is, of course, long after the attach() event has fired. If there was going to be a silent, automatic granting of permission, it would happen here, at least.

I think this confirms what the wiki shows: Teleport permission is not automatically granted.

I suspect that if the only permission I was asking for was attachment, it would silently grant the permission without showing a dialog. Otherwise, all those HUDs I've seen that have close buttons would be showing the permission request, too. I think it's just including it on the permission dialog because the two permissions are requested at the same time.

 

Edited April 28, 2017 by Lavanya Hartnell

[Rolig Loon]

This has been bugging me for the last 24 hours.  I finally got an Internet connection in a hotel that would let me log in to SL and check my own personal teleporter.  As I remembered, it does not request PERMISSION_TELEPORT explicitly.  It simply teleports me to the destination and sends me a quick notice to let me know that I was teleported by an object belonging to Rolig Loon.  Permission is granted silently, contrary to what the wiki says.

[Innula Zenovka]

Sorry for the delay in responding and sorry, too, for confusing the issue.  

After some tests, I think the OP and the wiki are correct in saying that PERMISSION_TELEPORT isn't granted silently to the owner even if the item is worn -- it doesn't seem to behave like PERMISSION_TRIGGER_ANIMATION. 

However, since I was sure that I'd once made something that doesn't keep asking the owner for PERMISSION_TELEPORT, I did a bit of playing around and came up with this.    It probably needs some tweaking -- if you give a copy to a friend who then attaches it, your friend gets a permissions request on attaching it, and then gets whooshed off to the destination --  but I think it covers all the bases, and asks the owner for permissions only once.

ETA  -- should be if (change & CHANGED_INVENTORY || change & CHANGED_OWNER) in the changed event, obviously.   For some reason I can't edit or replace the preformatted text in the script

integer iChannel;
integer iAttachmentPoint = ATTACH_HUD_TOP_RIGHT;
key kAv;
string strLandmark;

default
{
    state_entry()
    {
       strLandmark = llGetInventoryName(INVENTORY_LANDMARK,0);
    }
    
    changed(integer change){
        if(change & CHANGED_INVENTORY || change & CHANGED_INVENTORY){
            llResetScript();   
        }   
    }
    
    on_rez(integer param){
        if(param){
            iChannel = param;
            llListen(iChannel,"","","");   
        } 
    }
    
    listen(integer channel, string name, key id, string message){
        kAv = (key)message;
        if(llGetAgentSize(kAv)!=ZERO_VECTOR){
            llRequestExperiencePermissions(kAv,"");   
        }   
    }
    
    attach(key id){
        if(id){
            if(llGetPermissions() & PERMISSION_TELEPORT|PERMISSION_ATTACH) {
               //Don't need to do anything
            }  
            else{
              llRequestPermissions(id,PERMISSION_ATTACH|PERMISSION_TELEPORT);   
            }
        }
    }
    
    experience_permissions(key id){
        if(!llGetAttached()){
            llAttachToAvatar(iAttachmentPoint);  
        }   
    }
    
    experience_permissions_denied(key id, integer reason){
           if(!llGetAttached()){
                llRequestPermissions(id,PERMISSION_ATTACH | PERMISSION_TELEPORT);  
            }
    }
    
    run_time_permissions(integer perm){
        if(!llGetAttached()){
            if(perm & PERMISSION_ATTACH){
                llAttachToAvatar(iAttachmentPoint);  
            }
        }
        else if (perm & PERMISSION_TELEPORT){
            llTeleportAgent(kAv,strLandmark,ZERO_VECTOR,ZERO_VECTOR);
        }
    }

    touch_start(integer total_number)
    {
       if(llGetAttached()){
            if(llGetPermissions()&PERMISSION_TELEPORT){
                llTeleportAgent(kAv,strLandmark,ZERO_VECTOR,ZERO_VECTOR);
            }
            else{
                llRequestPermissions(kAv,PERMISSION_TELEPORT);
            }
        }
    }
}

Sorry for confusing the matter -- I now realise that almost all the teleport scripts I've written have used either RLV or experience tools, so I'm a bit rusty about teleporting people using run_time_permissions.    But I think Rolig and I are right that you need bother people for permissions only once whether you're using experience perms or run_time_permissions.

Edited April 29, 2017 by Innula Zenovka

[Lavanya Hartnell]

Okay, cool. That now perfectly meshes with what I've found. My users only have to grant teleport permission once (per HUD). It is retained across sessions of wearing, thankfully.

This isn't awful, of course. I was just hoping to make it so they would grant a permission (i.e., an entire experience) for the entire line of HUDs people may get in the future with this same script set. But it's clear to me, now, that experiences must be enabled at the parcel or region level. I'm disappointed that LL introduced yet another feature that had the potential to be more than it is. I shouldn't complain, though, because it's still a neat feature for a lot of game-like applications.

Incidentally, I'm not the first person to think of this. There is an "AVsitter" experience created for use with all the furniture that relies on the AVsitter kit. I guess I had been assuming it actually works grid-wide like what I want for my HUDs, but the evidence is that it doesn't. Again, each region or parcel would have to enable that experience, which requires parcel owners to even be aware of it in the first place.

Thank you all for your insights.

Edited April 29, 2017 by Lavanya Hartnell

[Berksey]

I'm wondering if the built-in limitations aren't there for reasons similar to a fix they did limiting llGetObjectDetails (due to an exploit used for stalking scripts)...

I sometimes get immensely frustrated when I hit a wall like that, but sometimes LL does seem to actually have extremely good reasons for some of the stuff they do. Adding functionality sometimes has unforeseen consequences, and rather than taking the functionality away, they limit it to prevent the exploitation of it. Lesser of two ebils, I spose. ^-^;

[Lavanya Hartnell]

I have to agree. The way LSL permissions work, overall, makes good sense, IMO. I don't think I'd want objects teleporting me without my permission, even if they are attachments. It would be nice if one could grant a permission to an entire product line, which I was hoping was what experiences were for. They only kinda are.

I'm being optimistic in hoping that users will soon be used to getting hundreds of my dynamic landmarks from places they visit, so I have an incentive to try to reduce this somewhat confusing barrier. Quite a few people who have tried out the HUDs don't actually see the permission request at first. I think more than a few have even just given up on it because they never noticed that permission box or payed attention to the plain-English messages the HUD repeatedly gives the user to explain the need. But this is a classic problem in user interface design, too. I'll continue working on a better answer.

[Berksey]

The permissions box is definitely a pain that way; sometimes people don't see it because it hides behind menus. By the time you can see it, you've closed the menu and the permissions box may have faded from view by then... My favorite sofa is a tad outdated, and does this; I have to remember the permissions box every time I sit on it. Almost not worth it, but yeah... favorite sofa.

[Lavanya Hartnell]

Definitely frustrating. I've learned not to show a dialog while waiting for the user to grant permissions because of that overlap. But even the inventory window, mini map, and other HUDs can obscure it. It doesn't help that it's dull in color to the point of blending in with always-there windows like the chat history or inventory box. At least dialogs stand out enough to draw the eye to them.

I've recently discovered that a lot of people are not aware of the floating icon indicating waiting system notices and requests that hide after a while. The system is polite but cryptic, especially for new users.

Edited April 29, 2017 by Lavanya Hartnell

[Nirea Mercury]

The Lab did announce back in March that user-created gridwide experiences are coming.  See 

Number 8 on the list of upcoming features was this:

Quote

Gridwide Experiences - Currently, Creators can use the increased scripting capabilities of an Experience only in a region or parcel whose owner has explicitly enabled their Experience. One of the new Premium abilities will be an Experience that is enabled anywhere on the grid unless the landowner has blocked it.