Qie Niangao

That part is interesting, inasmuch as the Bluetooth connection works with no issue until Firestorm tries to use it for a very slightly different thing. If you haven't already tried with a wired USB audio connection (Apple's USB-C EarPods are surprisingly not awful for the surprisingly reasonable price), it may be worth seeing if there's something amiss in Firestorm's voice configuration. Usually I'd fuss about the USB-Bluetooth adapter approach, which always caused me problems that magically went away when I got a motherboard with a proper Bluetooth + WiFi module, but if you're only having problems in p2p mode, that doesn't really seem like a Bluetooth problem. As you may know, the Lab is in the process of replacing Vivox with WebRTC, and on a pretty accelerated schedule. That might possibly fix stuff.

Yeah, this is one of SL's older self-inflicted wounds, confusing instance with class: mesh models are not first class assets to be manipulated in the world, where only individual instances of those models survive the upload process. This is unlike every other object primitive that can be morphed into any other by script. This decision to neuter mesh was intentional, as I understood it, in service of mesh modelers who feared IP infringement (which was a problem with sculpties and prims). Now it all looks pretty anachronistic. Soon enough human-crafted, artisanal mesh will be quaint, the hand-carded wool or hand-thrown pottery of virtual worlds, but SL will still prevent AI from morphing its mesh content.

"Firewall"? "The IP would only be exposed to LL"? Clearly this won't be simple peer-to-peer but I'm not grokking the architecture here at all. [EDIT: Okay, I finally read the SL Wiki article so I see the "relay" of the SL Voice Servers… which must be pretty clever beasts if listeners will be able to mix/mute separate audio sources within the region, which is kinda expected, right?] But then I don't know anything about how Vivox works now either, and strive to keep all SL audio muted as much as possible. Still… internet sing-alongs? That's gotta need some synchronization magic beyond my ken to not end up sounding like an echoey Zoom call.

I can confirm the Kama City phenomenon, at least in the far northwest corner. There were several quite pricey parcels here (well, it's double-prim) that sold, leaving just one still available in this region (Broadwater). Because the sales had (apparently) different prior owners and sold to (apparently) different buyers over the course of a few weeks, I'd guess they went at asking price or near it.

They may have also had privacy law problems, but also they were garbage. People were reportedly verifying as Elvis (not to disparage any theories of his ongoing presence amongst us).

However effective an age-verification method is (or isn't), there's much to be said for sticking with industry standard (which is, basically, asking nicely). If the company is fine with losing lawsuits left and right, then sure: get creative, hire an "age verification" service, etc. Remember Aristotle/Integrity? That might have screened out a handful of underage users but as I recall, it exposed more liability than it averted. This isn't legal advice, but there's much to be said for hiding in the herd, doing whatever everybody else is doing. This is nowhere to innovate.

It's certainly possible. Whether there's an off-the-shelf script that does exactly what you want may be hard to discover. (I, at least, have no idea, and don't know the scripts you mention which I gather are common scripts for doing something related.) There are shirts and pants scripted to change which parts are visible based on touch or HUD control, so maybe they're using a relevant script you could discover by inspecting demos. Passage of time, hmm… probably that, too, like wet clothes that dry off or something. If you were to ask someone to make this script for you (perhaps on the Inworld Employment forum) it may help to have a little more specificity on a few points. The surfaces involved are separate links in the linkset? Or separate faces of one or more links? These are discrete states, right? i.e., the surfaces are either visible or invisible, not transitioning through a continuous range of alpha levels? The textures are old-school "Blinn-Phong" materials, right, not PBR? (This one is kind of a big deal right now because we expect script control of PBR transparency to get a lot simpler soon-ish.) The state transitions trigger based on just the passage of time, right, until it gets to the final state? and then what should the wearing avatar do to restart the sequence? touch? (Ease of touch for the user can depend on attachment point and model geometry) a HUD? a chat command? And it's always only the wearer who can trigger the restart, right? What should happen when the item is attached from inventory, as when an outfit is worn or the user logs in? just continue where it left off, or reset to the first (or last) state? It's all possible regardless of those specifics, it's just a scripter would need to know. Also, this isn't a complex script in any case, but it could be really simple if the states were modeled either as the faces of a single link or all faces of a set of links; it's just ickier to have State One be several faces on several links, and State Two be several different faces on different links, etc.

This is complicated in a couple ways. First, just to get it out of the way, based on the four arrows control I'd guess that "orientation" actually means offset here, rather than rotation. Both are possible, but either way "it's complicated". As a first approximation, a script might call llOffsetTexture (or llRotateTexture) to change the simple diffusemap texture on a surface. These do not affect the normalmap and specularmap, however, so if those were used, this won't be good enough and three parameters will need to be specified (each also identifying the image to be used) with llSetLinkPrimitiveParamsFast : PRIM_TEXTURE, PRIM_NORMAL, and PRIM_SPECULAR. But that's for old style "Blinn-Phong" materials. For PBR, I don't know of a way to manipulate rotation and offset of the PRIM_RENDER_MATERIAL, and instead there are potentially four glTF override parameters, PRIM_GLTF_BASE_COLOR, PRIM_GLTF_NORMAL, PRIM_GLTF_METALLIC_ROUGHNESS, and PRIM_GLTF_EMISSIVE. Also, the glTF surface dimensions are defined differently (like the vertical offset is sign-inverted or something like that). So if the surface will be painted with both generations of materials (to remain compatible with pre-PBR viewers), there's some work involved on the object being textured. Of course the script in the HUD must communicate with the one in the to-be-textured object. Sorry, I have no idea whether such a script exists in the library or Marketplace or anywhere, really. Also, regarding the need to identify the images in texture-related calls to llSet*PrimitiveParams*, I recall some discussion about being able to specify that the existing image should be preserved and only manipulate other parameters, but I've lost track of if / where that is on any roadmap.

No, I was responding to Sid:

Love this. Turn AI James Madison loose on AI Antonin Scalia and see what becomes of the "originalism" conceit. Just don't give them pistols.

I mean, yeah, they're both payments that go mostly to the Lab, but they're buying different things, which I took you to deny by claiming it was delusional to pay for mainland. They'd only be buying (almost) the same thing if mainland couldn't be resold, which is how it works for estates, Linden Homes, and the hypothetical Mainland 2.0. As long as there's reasonable prospect of selling the mainland one buys, it's simply a different commodity. It's not that I'm arguing it's a good "investment" or anything—in one of these threads I recently called Mainland an anachronism—but it's still not delusional to pay for it. Also, at least for some Mainland, there's a reason for that "reasonable prospect" of somebody buying the land on resale: it's not as interchangeable as a parcel on Belli or a typical residential estate. Some folks want the predictability that comes with that kind of uniformity—Belli is a huge success because it offers just the right amount of customization for many (many) SL residents. But the "sense of place" of a Belli parcel is very attenuated compared to much Mainland where one parcel is remarkably distinct from all others; not surprisingly, those parts best retained value through Belli's growth (so far). I don't think anybody knows how much distinctiveness a Mainland 2.0 should have, at the cost of less predictability. Would that market want to bring their own structures as on mainland, where the neighbor's choice might be a little too "distinctive"?

Apparently, unless the account has already pre-approved the necessary tier on the Land Use Fees dashboard page, they won't be able to proceed past the confirmation page (e.g., https://secondlife.com/land/lindenhomes/confirm/Fantasy_1024), with the warning:

I guess they're the same the way buying a chicken is like buying a domain name: they both involve paying somebody for something. I thought the whole point of Mainland 2.0 was to make it different from Mainland by getting rid of that up-front charge and removing the ability to resell the land, as with Linden Homes and Estates, so I don't understand how it advances that argument by claiming that there's already no difference. If the idea is that the market should not value Mainland at all, there should be nobody willing to pay up-front for it with the expectation they may be able to recover some of that cost at resale, that's just denying the existence of a market that still exists despite competition from the Belli model now and earlier from Estates. I agree there's currently way too much Mainland supply for that market, so repurposing some of it for a new model is an interesting prospect, but doing away with the buy-to-resell model wouldn't come close to satisfying all customers of SL's Land product.

Okay, but estates have almost universally charged only rent for as long at there have been estates. I mean, it's not surprising we don't have to buy hotel rooms even though folks still buy homes. Or maybe more directly, people still buy condos that are very similar to rental apartments that only charge maybe first and last month deposits up front. That's not to say rentals and condos don't compete, and estate rentals compete with mainland purchases, too, but they're very different business arrangements for the resident.

Am I missing the joke here? Estates haven't stopped charging rent have they?

If you're still using a viewer without Advanced Lighting Model (so it's doing forward rendering), I think it will still have a nearest single-digit limit on light sources (like six or something). If so, you can stack a bunch of lights along the border, all emitting black, so avatars on your side of those emitters won't see lights emitted on the other side. It's been years since I've actually done that, but back then "nearest" was based on distance from the avatar, not the cam; that would be good in this case, if it still works that way.

Be that as it may, it's no accident that Belli parcels are sized to the bonus tier of the subscription levels eligible for them. (Well, I'm not sure who the 512 Belli trailers are supposed to target. I don't think they're particularly successful anyway, but it's weird that they apparently aren't available to Plus members, a subscription level I don't really understand either.)

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