Jump to content

Qie Niangao

Advisor
  • Posts

    13,340
  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. 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.
  2. 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"?
  3. 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:
  4. 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.
  5. 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.
  6. Am I missing the joke here? Estates haven't stopped charging rent have they?
  7. 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.
  8. 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.)
  9. 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.)
  10. 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.
  11. 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?
  12. 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
  13. 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.
  14. 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.
  15. 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.)
  16. 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.
  17. 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.
  18. 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.
  19. 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.)
  20. 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.
  21. 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.)
  22. 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?
  23. 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.
×
×
  • Create New...