Would you use an "attachment-scope Experience"?

[Qie Niangao]

This seems like a scripting question but not really: scripts wouldn't much change. Rather, it's a user question: Would you be more likely to use an Experience if it were in force only when you wore an attachment that obtained your Experience permissions?

This isn't a big philosophical difference because Experiences can always be enabled and disabled in the simple viewer interface. Even though it's simple, though, it's not something people do very often, so it's easy to forget how simple it is. But I think we could make it even simpler and more "automatic" for users if the Experience permissions were stored in an attachment. An Experience attachment might be worn as part of an outfit, for example, like a role-play HUD or combat meter, etc. We're already accustomed to those attachments taking a whole bunch of permissions (they don't even need to ask) because we know they're only in force while worn.

Unlike those other attachments that just grab permissions without asking, I'd suppose an Experience attachment would still need to explicitly ask for Experience permissions initially. I'd actually want it that way, although that presents an irrationally scarier prospect than it should, with that whole long list of things an Experience script can do. If users were actually presented with the list of (more and different) things RLV can do, they'd be similarly spooked, but I think the details of Experience permissions should remain explicit.

A practical change (and one that would require some server-side work) is that "attachment scope" shouldn't require land-scope enablement, but should comply with land-scope blocking. In practice, I don't recall ever seeing an Experience blocked at the parcel level, but it's an ability landowners should have. On the other hand, landowners shouldn't need to enable all Experiences individual visitors might want to have attached.

One example in a recent Forums thread reminded me that the ability of Experiences to help users effortlessly navigate their personal Environment settings is defeated because they cannot take that Experience with them to locations they may want to photograph or otherwise enjoy with their array of Environments. It can make a big difference, using a tailored UI script instead of wading through a viewer UI made cumbersome because it must support the entire array of use-cases. But scripts cannot help currently because they need Experience permissions to make user-requested Environment changes, and users aren't able to take those permissions with them. That's why I think we need this.

[Love Zhaoying]

14 minutes ago, Qie Niangao said:

Would you be more likely to use an Experience if it were in force only when you wore an attachment that obtained your Experience permissions?

I suppose there is not much difference between this and a "grid-wide Experience", except you only participate in the Experience if wearing the attachment..couldn't that distinction just be checked by a script in the Experience?

I can see this being a valuable option for "Learning Second Life", if the attachment was maximum size, and could point the user towards different options and help messages..

[Qie Niangao]

1 minute ago, Love Zhaoying said:

I suppose there is not much difference between this and a "grid-wide Experience", except you only participate in the Experience if wearing the attachment..couldn't that distinction just be checked by a script in the Experience?

Not sure I understand. I guess if one were starting from a grid-scope Experience, scripts compiled to that Experience could check that the user is wearing a script compiled to that same Experience (or something), but that's not very reassuring to users who only want to participate in the Experience while wearing the attachment: how can they know all scripts in the Experience enforce such a check on themselves? 

But I could be missing the point. Grid-scope Experiences are such rare unicorns I've never taken them seriously.

[Love Zhaoying]

4 minutes ago, Qie Niangao said:

Not sure I understand. I guess if one were starting from a grid-scope Experience, scripts compiled to that Experience could check that the user is wearing a script compiled to that same Experience (or something), but that's not very reassuring to users who only want to participate in the Experience while wearing the attachment: how can they know all scripts in the Experience enforce such a check on themselves? 

Here's some ideas on how that could be done:

1. Restrict creation of Experience Scripts to only "trusted" groups/users/etc. (such as "Experience Owners").

2. Make "Experiences" so that they are "restricted" so you can't create a script for the Experience unless you are an "Experience Owner", etc.

- Isn't this already true? Can any Tom/Dick/Harry create scripts for any grid-wide Experience?

ETA: Sounds more like a "permissions issue" than anything, to me..

Edited March 10 by Love Zhaoying

[Qie Niangao]

1 minute ago, Love Zhaoying said:

Can any Tom/Dick/Harry create scripts for any grid-wide Experience?

Well, that's what I mean about rare unicorns: As far as I know, nobody except Lindens and their unindicted co-conspirators have created a grid-scope Experience since that beta closed, about a decade ago. So putting an attachment-enabled Experience feature behind a grid-scope Experience prerequisite would only be useful if they started minting those again, but after all these years of begging, I don't see that happening.

[Love Zhaoying]

5 minutes ago, Qie Niangao said:

So putting an attachment-enabled Experience feature behind a grid-scope Experience prerequisite would only be useful if they started minting those again, but after all these years of begging, I don't see that happening.

So perhaps, that could be the "ask" - allow creation of grid-wide Experiences, but tie them to only work if user has Attachments running scripts for that Experience.

I hope that makes more sense than my previous reply LOL!

A few use-cases:

- Grid-Wide Combat Experiences requiring certain brands of HUD

- Grid-Wide Mesh Body Experiences requiring Experience connected HUD

- Grid-Wide Shopping Experiences requiring Shopping HUD

- Grid-Wide Hunts requiring Hunt HUD

 

[Zalificent Corvinus]

Listening to you two gabbling at each other suggests you both live in some "head jammed up a compiler's rectum" cloud-cuckoo-land, where you are oblivious to the real SL.

 

5 hours ago, Qie Niangao said:

the ability of Experiences to help users effortlessly navigate their personal Environment settings is defeated because they cannot take that Experience with them to locations they may want to photograph or otherwise enjoy with their array of Environments

Heads up, we don't need a stinking "Experience" yo "enjoy" our own choices of EEP, many of us use TPV's which allow us to just pick one we like off a list, and leave it at that, ALL THE TIME, and we can change to another just as easily for a photo. I understand that "persistent personal EEP settings" might be a TPV only option, but that would be an argument for not using the official Fail-Viewer, rather than trying to force "Experiences" down peoples throats. Again... 

 

4 hours ago, Love Zhaoying said:

I can see this being a valuable option for "Learning Second Life", if the attachment was maximum size

Seriously? We apparently have a "noob retention issue" already with SL being too hard and too scary for people with "low comprehension", and YOU want to add a screen covering hud that slaps them with a scary permissions popup?

"The Why-No-Clue-O Abuse-A-Noob Help Hud Experience would like permission to take over your viewer and do a bucket list of things to you most of which you don't understand. Accept? YES / NO"

"Hey, where did the Noob go? Oh YET ANOTHER SL-TOO-HARD-&-SCARY retention fail!"

 

4 hours ago, Love Zhaoying said:

1. Restrict creation of Experience Scripts to only "trusted" groups/users/etc. (such as "Experience Owners").

2. Make "Experiences" so that they are "restricted" so you can't create a script for the Experience unless you are an "Experience Owner", etc.

Creating "Experience" code is already gated to "officially nice people" that is "premium subscribers", and you can't create for somebody else's "Experience" key unless you have a specific role power in a group they made for that purpose. Try and keep up.

 

4 hours ago, Love Zhaoying said:

A few use-cases:

- Grid-Wide Combat Experiences requiring certain brands of HUD

The kinds of things a "combat" hud might need Experiences for are already done more easily and better with RLV/RLVa, which is why some combat systems already use that.

 

4 hours ago, Love Zhaoying said:

- Grid-Wide Mesh Body Experiences requiring Experience connected HUD

I cannot think of a single legitimate reason for any mesh body having any kind of Experience control over my viewer, ever. I don't want to be force sat, or force teleported, or have my personal EEP messed with, or my camera aimed, or attachments I didn't ask for stuck on me,  by a mesh body I'm wearing.

 

4 hours ago, Love Zhaoying said:

- Grid-Wide Shopping Experiences requiring Shopping HUD

I decide where and when I shop, not a "shopping hud". NO legitimate use for Experience powers there either. Wear a hud, accept the scary permissions, so you can be griefed commercially by greedy merchants? Oh HELL no.

 

4 hours ago, Love Zhaoying said:

- Grid-Wide Hunts requiring Hunt HUD

Seems legit, what could go wrong with a hunt hud that turns your EEP to "too dark to even see where you are walking" and force tp's to back to the store entrance when you get too close to their hunt prize, until AFTER you gave them a whole 30 mins of free "live human traffic bot" traffic points.

That wouldn't kill off hunts dead at all

</sarcasm mode>

 

 

[Qie Niangao]

4 hours ago, Love Zhaoying said:

So perhaps, that could be the "ask" - allow creation of grid-wide Experiences, but tie them to only work if user has Attachments running scripts for that Experience.

I hope that makes more sense than my previous reply LOL!

A few use-cases:

- Grid-Wide Combat Experiences requiring certain brands of HUD

- Grid-Wide Mesh Body Experiences requiring Experience connected HUD

- Grid-Wide Shopping Experiences requiring Shopping HUD

- Grid-Wide Hunts requiring Hunt HUD

I'm not sure what the Experience features would be in these cases other than Combat and other "gaming" now that the game controller interface is almost live and the Pew-Pew Crew meetings are ongoing. But I'm sure something creative could emerge. Honestly, I've been stuck thinking about Experiences as "land scope" so long now I've kinda lost track of my original hopes for them. 

I would just reiterate, though, that if this is presented as grid-scope experiences with an attachment requirement, I think it's doomed. I think it might have some hope of success if pitched as a natural extension of the way attachments already get permissions (and can use them anywhere), just with the extra precaution of explicitly asking for the extended permissions and allowing landowners to disable them if desired.

23 minutes ago, Zalificent Corvinus said:

Listening to you two gabbling at each other suggests you both live in some "head jammed up a compiler's rectum" cloud-cuckoo-land, where you are oblivious to the real SL.

If my imagination were limited to your "real SL" I'd never have logged in past 2006.

[Zalificent Corvinus]

46 minutes ago, Qie Niangao said:

If my imagination were limited to your "real SL" I'd never have logged in past 2006.

By "real SL" I didn't mean "SL that's like real life", I meant "the SL everybody but you two uses".

 

As in the difference between Love's suggestions for "use cases" and what people who don't spend all day standing around with their heads jammed in an lsl editor, making "advanced experiments in theoretical lsl, for apps nobody wants, in a hypothetical user free environment" scripts while being at least 10 years behind on knowing what everyone else is up to. Things like...

"Lets improve noob retention by slapping them with a scary permissions popup that promises a total loss of control over their SL" vs "Great way to get EVEN MORE noobs to rage quit in the first 5 mins in SL"

Or..

"Lets allow the maker of your mesh body to decide what EEP you use, where you go, and when you sit, and what direction you are allowed to look in, because wow, experience-abuse  coders are leet and should be allowed to bully mere users, because they are BETTER PEOPLE who are trusted to rule the grid because they paid for Plooooooooose""

 

Like I said.

1 hour ago, Zalificent Corvinus said:

"head jammed up a compiler's rectum" cloud-cuckoo-land

 

Edited March 10 by Zalificent Corvinus

[Arielle Popstar]

1 hour ago, Zalificent Corvinus said:

"Lets improve noob retention by slapping them with a scary permissions popup that promises a total loss of control over their SL" vs "Great way to get EVEN MORE noobs to rage quit in the first 5 mins in SL"

If it was to do a total makeover experience that gets me looking more how I would like to look, I'd be all for it as I'm sure a lot of noobs would be.

[graceblakeley]

14 hours ago, Qie Niangao said:

This seems like a scripting question but not really: scripts wouldn't much change. Rather, it's a user question: Would you be more likely to use an Experience if it were in force only when you wore an attachment that obtained your Experience permissions?

I am just an ordinary, common or garden user of SL.

I don't like being prompted to Accept an experience, I never Accept, but I don't want to Block Experience either as I wouldn't know how to reverse that decision if I ever wanted to. I just say No. I don't even want to be asked that question in the first place. I don't trust it, just like I wouldn't click links in an email from an unknown source or off some random website. Avoid. Depart. Leave without clicking anything. That's what I do.

Wearing an attachment or not would result in the same outcome for me, but I wouldn't want that attachment in the first place. I don't want this experience. I don't see the value of it. Please don't try and explain what they are and how great they can be as I can function quite happily in SL without these experiences. Just leave me alone.

[Qie Niangao]

5 hours ago, graceblakeley said:

Just leave me alone.

Currently there's no way to prevent all Experiences from ever asking a specific resident whether they want to participate, but it certainly doesn't advance my proposal to have users getting annoyed by requests they don't want to see. The Lab is not going to deny everybody else the opportunity to use the Experience feature, so instead would it help if you could choose a preference that suppresses all prompts to participate in any Experience?

Such a preference could (and probably should) be handled local to the viewer, so I wonder if any third party viewers already have a setting to simply ignore all optional Experience-related content. Maybe you could make a feature request for your usual viewer to change that? 

[Anna Salyx]

I really do like certain aspect of Experiences.  I like being able to touch my coffee/tea maker in my home and have it make coffee then auto attach to me so I can "drink" it, then detach after a time when the cup is supposed to be empty.  I like when I choose a sit in a Sofa/Chair/Bed that if has props that they can just be there when they are needed without me having to either accept an inventory offer and manually attach it, or give permission every time it wants to do the temp attach thing.  I like some of the Experience teleport items too that make moving around an area (or even to related regions) fairly effortless and mostly seamless.  There are aspects of the Experience I have never personally ever had acted on (cameras and controls in specific) and I'm opted into some 40ish Experiences, and none blocked.*  But I can see where those options might be useful in a niche sort of way.  I do generally accept most experiences when they are offer up because revoking them if they turn...unsavory is quick and easy.   That said, I do like that experiences are land based and not something we carry along with us. (KVP aside, but that feature has been detached from the land if I recall correctly). 

I personally think that the perceived dangers of Experiences, as with RLV, is overly amplified (if not exaggerated by some).  I also do think that they permission pop up is a bit overly dramatic and frightening the first time or 3 that it's presented to the user and that really doesn't help.  With some work it could be made more informative, less scary, and lessen the trepidation that people might have about Experiences be more inclined to give them a try.  (RLV is a different discussion not suited for here.)

and as easy as it is to revoke an experience should the need/want arise, I think a viewer option (kind of like a HUD button) that would appear and tell you  when and what Experience actively starts operating operating on your avatar, with an easy to click button to revoke permissions right there screen.  The script still has to check to see if you are in the experience and when it does, it *should* be fairly simple for the simulator software to send a flag to the user that could be caught by the viewer to do it's thing. 

 

---

* I should probably go in and clean out some of those, but I'm lazy.

[Qie Niangao]

26 minutes ago, Anna Salyx said:

That said, I do like that experiences are land based and not something we carry along with us. (KVP aside, but that feature has been detached from the land if I recall correctly). 

Right, a land-based Experience's KVP is now grid-wide, which is a huge boon to scripting anything that needs to do interregional object-to-object communications, especially broadcast messaging and access to a common data store.

But could you elaborate on why you favor land scope for Experiences, "not something we carry along" (attachment-based)? I'm genuinely interested in whether there's a reason here I should just drop this idea.

Not to argue the point here, but to give another example: I too really like the Experience-enabled props. I'd like to take that one with me so it works on furniture that was designed for its use, even if the furniture owner never enabled it on the land. I encounter that all the time. There are reasons they don't enable the Experience besides just not getting through the About Land interface to make it happen. For one thing, the furniture owner may be a renter, and the landlord may not respond to tenant requests.

Or even—something I never thought of until the previous post—the landowner may not want to let their furniture annoy folks who don't want to see the requests but don't want to block them either. That's really a reason for attachment-scope Experiences: folks who want to use furniture designed for an Experience could carry that ability with them, without the furniture needing to ask others for land-scope permissions. (People who grant those permissions already never see those requests again, but folks who won't grant nor block the permissions must see them all the time.)

[ValKalAstra]

Honestly, it's a good question. I'm a novice scripter myself and whenever I look at experiences, I find them oddly limiting and cumbersome. When I look at them as a user, I find them rather ominous with that popup. I want to teleport - why do you need that camera permission again?! (yah I get it, llRequestExperiencePermissions but... like why?).

I do understand the desire for an attachment scope experience but at that point - and pardon my ignorance - why not roll the functions into the normal script corpus at that point? But again, might be my ignorance on why something like environment settings need to be on experiences in the first place and can't be a normal function behind a targeted permission request.

/edit: Oh, totally forgot to answer your question:

I probably would use them. Yah. Although it might bump into attachment limits for avatars.

Edited March 11 by ValKalAstra

[Modulated]

I personally do not like forced experience acceptance for access. I think everyone should experience SL in the way they want to, regardless if the experience is what is preferred by the sim owner. If the experience is mandatory to visit, I refuse and I am not coming back/won't recommend the place to anyone.

[Qie Niangao]

1 minute ago, Modulated said:

I personally do not like forced experience acceptance for access. I think everyone should experience SL in the way they want to, regardless if the experience is what is preferred by the sim owner. If the experience is mandatory to visit, I refuse and I am not coming back/won't recommend the place to anyone.

That's fine. I'm sure the sim owners realize that some users won't accept the Experience but there's just no point in visiting the region without the Experience enabled, which is when Estate regions can specify those mandatory "Key" Experiences. So it all works out for the best.

But that's not what this is about. There are increasingly common casual uses for Experiences that come up routinely in SL now, but the interface to accepting or denying them is both scary and cumbersome, so I'm looking for ways to streamline that, and feedback on one possible approach.

[Modulated]

7 minutes ago, Qie Niangao said:

That's fine. I'm sure the sim owners realize that some users won't accept the Experience but there's just no point in visiting the region without the Experience enabled, which is when Estate regions can specify those mandatory "Key" Experiences. So it all works out for the best.

But that's not what this is about. There are increasingly common casual uses for Experiences that come up routinely in SL now, but the interface to accepting or denying them is both scary and cumbersome, so I'm looking for ways to streamline that, and feedback on one possible approach.

Really not sure what you mean by streamlined. The experience is going to have to be explicitly accepted or refused, regardless of dialog  , no? Otherwise it would be a violation of some sort I think.

[Qie Niangao]

21 minutes ago, ValKalAstra said:

why something like environment settings need to be on experiences in the first place

That's a good question. I'm not sure whether it would be analogous to llTeleportAgent() which is only available on items owned by the to-be-targeted agent, not including temp attachments, or if Environment management could be on some less constrained permission. (I don't think there's any explicit permissions for it now, kinda like llSitOnTarget().)

Good point about attachment limits. It's something I never think of, but I know it's a real thing, especially with no-mod fitted mesh. (With modifiable fitted mesh, can just link a bunch together in one attachment and let the parts land where they belong.)

[Qie Niangao]

1 minute ago, Modulated said:

Really not sure what you mean by streamlined. The experience is going to have to be explicitly accepted or refused, regardless of dialog  , no? Otherwise it would be a violation of some sort I think.

Yes. Well, I mean we're talking about a change to the functionality, so whatever it is, it's defining what is and isn't a violation, but I'd think it would still require acceptance. There is active discussion right now about how to make that particular permissions dialog less crazy scary with the whole long (but still incomplete) list of obscure possibilities, but yeah, whatever happens with that, I'd suppose it would still apply the first time an experience was enabled by an attachment, too.

By streamlined, I mean that an attachment-scope Experience would be up to the person who enabled the Experience on their avatar, not limited to the landowner (who could nonetheless explicitly disable the Experience on their land). That also means Experiences could be used in creations that are more avatar-oriented and less land-oriented.

I guess for completeness I should mention that when researching this idea I noticed another proposal that would do away with the whole permissions dialog in certain circumstances. I don't believe that's been elevated to "Tracked" status at this point, and I really don't have an opinion one way or another about that one.

[graceblakeley]

3 hours ago, Qie Niangao said:

Currently there's no way to prevent all Experiences from ever asking a specific resident whether they want to participate ...

Firstly, my apologies for perhaps being a bit over-dramatic with my post above. I am not a fan of Experiences, as you can tell, and I took my dislike and mistrust of them out on you to some degree and it is for that which I apologise.

I don't know you, but I recognise your name and am aware that you are extremely knowledgeable within our community. The community always needs people like yourself and I recognize that you are trying to help. 

[Anna Salyx]

1 hour ago, Qie Niangao said:

But could you elaborate on why you favor land scope for Experiences, "not something we carry along" (attachment-based)? I'm genuinely interested in whether there's a reason here I should just drop this idea.

In my mind, it'd be a form of fail safe escape.  If some Experience goes rogue, or goes in directions one doesn't like, the worst case scenario is to log out and log in at a "safe" zone that doesn't have the experience.  Similar to disabling RLV and relogging that is sometimes needed.  If you carry the Experience along with you as an attachment (not temp), easily escaping it becomes more frustrating maybe.  I don't know, that might not ever be a thing, but that is that idea that drove my reason there.

Quote

Not to argue the point here, but to give another example: I too really like the Experience-enabled props. I'd like to take that one with me so it works on furniture that was designed for its use, even if the furniture owner never enabled it on the land. I encounter that all the time. There are reasons they don't enable the Experience besides just not getting through the About Land interface to make it happen. For one thing, the furniture owner may be a renter, and the landlord may not respond to tenant requests.

But the thing is, those Experience enabled props are really only useful in that sense when combined with the actual furniture or associated land object.  The furniture rezzes the object, tells the object your UID Key and the prop's Experience script does the rest. If you take the prop along with you to use in places where the experience is not enabled, you'd still have to manually find it inventory and attach it yourself. Any added functionality at that time can be achieved w/out actually needing the Experience. Additionally to get the prop to take along the furniture or object would have to give it to you, which further defeats the reason for the Experience. And that all combined functionally nullifies the usefulness of the Experience itself. At least for prop based furniture/objects.  

It might be useful if you are carrying your own future around and wearing to use (or rezzing if you have rights), but honestly that's so much an edge case that I can't see the need to devote development time to a carry along Experience.

Quote

Or even—something I never thought of until the previous post—the landowner may not want to let their furniture annoy folks who don't want to see the requests but don't want to block them either. That's really a reason for attachment-scope Experiences: folks who want to use furniture designed for an Experience could carry that ability with them, without the furniture needing to ask others for land-scope permissions. (People who grant those permissions already never see those requests again, but folks who won't grant nor block the permissions must see them all the time.)

GraceBlakeley's comment "I never Accept, but I don't want to Block Experience either as I wouldn't know how to reverse that decision if I ever wanted to.", aside, most people who don't want to be bothered by the experience query pop up are going to block the experience and so won't be constantly bothered by them.  It'd be once ever for that given experience block and no matter where they go after, no pop-up.  So that's not really a good reason either, IMO.

[Anna Salyx]

I guess my real question is: what would an Experience be doing that would be benefited by making it carry along.  Most uses I see for it are for props, special events that are region/sim bound, or for RP purposes which again is region/sim bound. Neither of those scenarios in my mind benefit from being able to carry along the Experience in a worn object. The only benefit I can see is that it takes some underlying "paperwork" away from the region/sim/parcel owner in that they don't have to explicitly allow the Experience on their land.  I think, personally again, that the resources and time is better spent in making a less scary pop up asking for permission and maybe some PSA's about what experiences can do, what they *cannot do* and the likely hood of each ranked most common to least common.

And for Experience Teleports, to ease concerns about abuse of them, maybe make anything that takes you to a different sim still require an explicit pop up acknowledgment to proceed, but teleports within the sim would be automagic.

==

Edit:

After looking at some of the experience tools in LSL I see that environment is one that might be handy to have on a carry along. For that I'd rather see a couple of LSL commands that auto-grant on being worn that do the same thing (and and maybe can't work on non-owner avatars) instead of reworking the Experience system.

Edited March 11 by Anna Salyx

[Qie Niangao]

7 minutes ago, Anna Salyx said:

If you carry the Experience along with you as an attachment (not temp), easily escaping it becomes more frustrating maybe.

The "easy" way out would be the viewer's interface for adding, forgetting, and blocking Experiences, which is pretty easy to use (certainly easier than teleporting to a new region) but maybe not very well known. Maybe the permissions dialog should be more explicit about that. Certainly, if I go ahead with a feature request, I should make clear that attachment-scope Experiences must be subject to being disabled in that same interface (unlike some grid- and land-scope Experiences that just won't go away—which may actually cause confusion about how to get out of usual resident Experiences).

16 minutes ago, Anna Salyx said:

If you take the prop along with you

Oh, I made that confusing somehow. An attachment-scope Experience wouldn't take the prop along, it would just enable the Experience that attaches props, same as its land-scope flag. The idea in this use-case is for a user to be able to select for themselves that prop-attaching furniture can indeed attach props, without needing the furniture owner to set it up (which may not be possible if they're a renter).

22 minutes ago, Anna Salyx said:

most people who don't want to be bothered by the experience query pop up are going to block the experience and so won't be constantly bothered by them

That's probably true. Until this thread I never even considered it. But I still wonder if some landowners avoid Experiences just because they don't want visitors to confront the scary dialog.

Regarding role-play, not all such activities are bound to regions, especially on Mainland and Belli. For example, there's a tour of Belli rail that seems to be popular, maybe inspired by (or inspiring?) a very successful Valentine rail tour run by Lindens and Moles. I could definitely see enhancing that group tour with an attachment that could add a little dynamic Environment "weather" along the way, and maybe offering to retrieve and re-seat any stragglers thrown off by region crossings.

I'm sure there are games that would be more fun to play on Linden roads, rails, and water, if they could be augmented by Experience abilities not otherwise available to attached scripts.

[Love Zhaoying]

Help me with this logic - am I wrong in some of these points?

- Experiences are only "relevant" in the scope of Scripts (nothing is aware of an Experience except Scripts). In other words, "you have to use an Experience-relevant script to participate in the Experience".

- Only Experience "owners" (or those with the appropriate Experience "rights") can create a Script connected with a particular Experience. If true, then to me this means "nobody else can create a Script relevant to 'my' Experience (an experience that I 'own' or control)".

If both of the above are true, then it seems to me the only thing lacking is the ability to have grid-wide Experiences.  Whether an Experience requires a HUD would be determined by whether the only "valid" scripts for the Experience are part of a HUD or not.