Qie Niangao

I don't recall saying that, although I'm not entirely sold on the idea. And I suppose I do think technically "many people" would refuse this opportunity because not everybody is ever going to go Premium at all, or tier-up to the level needed to support a 4096. What I tried to explain before is that 4096 is a particularly difficult size for Premium subscribers with the standard 1024 m² bonus tier. It may be a popular size on Estates, but I assume most Mainland and Belli owners are at the 1024 level, many with no other holdings. Tiering up from 1024 to 4096 leaves that whole 1024 "left over" in the current tier structure. Crap. So now I need to break out the spreadsheet to see if this makes Premium Plus super attractive: Well, sort of, I guess, so maybe the Lab could market these 4096s as an incentive for stepping up to Premium Plus, maybe offer some special pricing for Premium Plus tiers in general. (E.g., if Premium Plus got that extra 2048 for $9.50 per month instead of $13, they'd pay $363 per year for 4096, same as Premium, with all PP's extra benefits instead of the spare 1024.)

Yeah, but before Belli, many folks who were sick of Mainland anarchy abandoned their Premium subscriptions and moved to Estates. Now many of them have another option. Any Estate owner who serves the lower end of residential cannot possibly miss the competition from Belli.

See also https://replika.com/

Have you looked at the map? That space between the old Mainland continents, remember that? It's full of Bellisseria. Private Mainland is an anachronism. Residential Estates are next. Ideally there'd be so much expanded demand that it would fill all that new capacity with enough to spare to still fill the old Mainland and Estate models. But that would be asking an awful lot. Really, just look at all that added land. Maybe eventually the Mobile Viewer will fill the obvious gap. Or maybe not, but that viewer doesn't exist yet, so yeah: obvious gap. Why does Bellisseria trounce the older SL Mainland product, and why are Estates less affected? Gosh, what could they have in common?

Rose Courteau, in "Our Anesthetized Culture: Kyle Chayka’s Filterworld", The Rumpus, January 30 2024 following up "How to save culture from the algorithms", Decoder, March 11 2024

Sorry, I'm a little busy in RL right now so I can't respond as efficiently as I'd like, and you raise good practical considerations. The way I see it, experience permissions granted in an attachment should apply (almost) exactly the same as how all existing attachment-enabled permissions are handled, so if detached, they just don't apply to the avatar session unless/until reattached. The big difference is that existing attachment permissions are for the scripts inside the attachment, whereas the experience attachment permissions would be obtained by other scripts (attached or not) based on the fact the experience permission-granting attachment is being worn and the land doesn't disable it, in contrast to how land-scope experience permissions require the land to have it enabled and the avatar account to have it approved. It doesn't seem that much different, but I'm sure there are details to be designed. For example, I don't know how it works now if I use the viewer UI to "forget" a land-scope experience that a script is using; however that works might be what happens when an experience attachment is detached. I guess I have been tacitly assuming that the "experience permission-granting attachment" holds that permission in an Experience script, but a developer might prefer to use some other authorization token instead. I'd expect that most experience permissions would just naturally be associated with pre-existing HUDs. I do see, however, some utility in being able to combine more general purpose experience permissions in a single attachment, to store those we want to use grid-wide even though they're not grid-scope experiences for everyone. Right now, the only one of those I know I'd want is, indeed, AVsitter, but other attachment-scope experiences might emerge if the feature were available. Anyway, yeah, managing combined experience permission tokens/scripts in a single attachment might need some design work to keep it simple.

There's really nothing about this proposal that would require merchants to use the feature in the worst possible way and make it mandatory for their customers.

I keep forgetting how much there is to Experiences that many folks just haven't encountered. It took me a bunch of posts in this thread before I even got around to mentioning dynamic Environment "weather". It's a tremendously immersive effect, a whole other level of "environment" from static EEPs. The associated Experience would presumably be part of a general role-play / travel HUD, not requiring an additional attachment slot just for the Experience. (I had a land-based version of this for a few years offered from my Belli houseboat so the "front" could come in off the water, etc., but on a tiny Belli parcel it can't be as immersive as riding a train or a sailboat through a multi-region "storm" might be.)

Yes, either "accept" or "block" will make it simply go away until they specify that they want to "forget" it. From a scripter's standpoint, sure, if we all had grid-scope Experiences we could do everything the attachment-scope Experiences would enable. But there are two other players here: the Lab, and residents who may or may not want to participate in the Experience. Residents may not want to participate in an Experience all the time. Sure, they could "forget" it in the viewer interface and then approve it again the next time, but I'd think having something embedded in an outfit, for example, would be simpler to manage, like other attachments (or often embedded in such attachments, such as HUDs). The Lab, I presume, is cautious about grid-scope Experiences, mostly to keep Residents from being unpleasantly surprised by unintended teleports etc.

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). 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). 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.

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.

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.)

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.

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.)

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?

It's enough to get it cached (as is asking for the count of lines) but there's no guarantee it will stay cached for any length of time. It's possible the notecard will be cached to fire the dataserver event and then the region crashes or is restarted before even a single llGetNotecardLineSync can return, or at any time thereafter, so then it'll need to be recached before any -Sync calls can proceed. Of course it's much more probable that once cached the notecard can be synchronously read to the end, so from a performance standpoint it's a huge win. But still need to handle those NAK exceptions at any time, so the program flow can't be that simple.

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. If my imagination were limited to your "real SL" I'd never have logged in past 2006.

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.

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.

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.

I too never get a notice when logging in, but check the group notices. (I must have nerfed my group settings or something. Somehow I get announcements from other groups but not this one. Ironically, Firestorm often dredges up group announcements that I already saw ages ago in one of my usual viewers.)

Works here. Try this in the root of a linkset you don't mind having recolored: default { touch_start(integer total_number) { integer link = llDetectedLinkNumber(0); llOwnerSay("Touched link: "+llGetLinkName(link)); llSetLinkColor(link, <llFrand(1.0), llFrand(1.0), llFrand(1.0)>, ALL_SIDES); } } I guess if that doesn't work, try a different region? or show some code that isn't working?

Okay, sorry, I was checking with an account that has never gone Premium at all, and it didn't have a next bill date, but maybe once you go Premium you get a next bill date forever, even when the bill is zero... which is what I hope you see in the "Total monthly cost" above that bill date. (I don't have any account that used to be Premium but isn't now, so I can't actually confirm that ex-Premium accounts still have "next bill dates" even though they won't be billed, but it sounds plausible.) So, now, backing up to your original post on March 5th, probably you were billed March 4th for land you held even briefly at any point after February 4th. If instead you're sure you cancelled everything before February 4th, you should definitely contact Billing. (Their phone numbers are here along with links to submit a support case if that's easier.)

I knew I remembered this came up somewhere fairly recently. This is extracted from chat at the Simulator User Group a few weeks ago (eliding interspersed discussion of swimming): So maybe check-in with dantia Gothly (or, if I've just outed an alt, sorry 'bout that!).

Every time I see the original post quoted, I get a little shiver when I think about "straight talk" "from Brad." Even before the salacious stuff the thread is presumably about, SL presented some recent personnel challenges that, if I were in his position, would really test my patience. Every day that we don't hear what I've been fearing Brad would say is some reassurance that he won't be saying it… this time around.