Qie Niangao

I'm glad you did because it give me an opportunity to do some truth maintenance on something I said which is no longer correct: In fact, Experience KVP (the persistent data store) is no longer locked to the land scope of the Experience itself, so grid-wide communications are possible using it as long as you can compile to an experience with some spare capacity in that relatively capacious store. It's roll-your-own message queueing protocol, and it's polled instead of async, but it's otherwise low overhead, broadcast, and very fast so it's perfect for single-sender / multi-recipient messaging but can easily be extended to multiple senders. That's not exactly on-point to the original 2018 topic, but I wanted to mention it anyway because grid-wide object-to-object communication comes up often.

Possibilities for objects to vanish without a trace: While you were gone, region state rolled back to a time before your items were rezzed. Then they're gone. This should only happen when the region owner requests it, so maybe ask them. The items deleted themselves by calling the llDie() script function. Some commercial creations, especially no-copy stuff like breedables, are programmed to verify that they're legit and delete themselves if they "decide" they're not. This process must be utterly reliable, which is essentially impossible in SL. Might check with the breedable creator to see if they'll admit to using such logic. The items deleted themselves with a different kind of bug, in one of several ways: They could set themselves PRIM_TEMP_ON_REZ. Or STATUS_DIE_AT_EDGE or STATUS_DIE_AT_NO_ENTRY and stumble their way off the grid. Theoretically, there could be a bug in the region code. This bug, though, would have to be incredibly rare or it would be very apparent. If I were a betting man, my money would be on #2, but mostly because of this "breedables website" listing: How does that work such that an item could be automatically unlisted when it vanishes? I've always avoided breedables so I don't know how this works; do you? or is it possible to find out? Whenever items contact a central server for any reason, ever, I'd suspect something awful until proven innocent. This isn't to suggest contact with the listing website itself caused the problem (assuming it's not run by the items' creator) and they might be worth contacting to see if they've heard of something similar. [ETA: I never rely on a viewer's "area search" function for anything critical. The Build / Pathfinding / Region Objects window gets more directly at the simulation's own idea of everything on the region. But it usually doesn't matter.]

Right, I know to what you're referring, but if that were a factor in this timing I'd have thought Wendi would know about that by noon of the 27th. But yeah, that might have something to do why "I'm curious what became of this video". (FWIW, the Concierge group meeting had a perfectly "business as usual" tone, as did the Simulator group on the 25th although there was quite a gaggle of Lindens at that Simulator one—which might have been simply because the meeting introduced and welcomed a new developer, Pepper Linden, to the team.)

Did this happen? As @ItHadToComeToThis pointed out, the Feb 21 blog announcement offered "an all-new pre-recorded Lab Gab scheduled to air on socials in the near future" which I took to mean it would appear on YouTube with scheduling details to be announced wherever LL posts stuff these days. But I don't see it on the secondlife YouTube channel, so maybe it went straight to some social media or other? Or just wasn't (yet) uploaded at all? Because I'm not Premium Plus, I'm not that impatient to hear about the mobile viewer itself, but now I'm curious what became of this video. And I guess I'd be interested to know when I might expect to put it on my iPad, in case it's the killer tablet game that market needs. ETA: I guess X is still a social network, kinda, and it got a post with date and time (but posted on the 21st, same as the blog announcement) :

I'm curious which feature(s) you have in mind here. Because the one that springs to mind for me is Windlight, which was very controversial and widely reviled when introduced because it made everybody's builds and avatars look quite different. But the platform grew immensely following the Windlight rollout, so maybe we were just made of sterner stock back then.

This is a scripted rezzer, right? I mean, it doesn't hand out balloons that the visitors need to rez themselves, right, but is supposed to rez them itself? Assuming this is on your island, I checked and the whole region is a single parcel owned by you and set to a group, but the land permissions disallow building (rezzing) by Group. Scripted objects owned by you should still be able to rez, but not those owned by other group members. And of course nobody, including group members also can't rez anything from inventory onto the ground here. But unless that land setting changed, these shouldn't have worked moments ago, either, so maybe this isn't the place? Sure are a lot of balloons around here, though, hehehe!

I was (only?) half kidding: Linden Lab may be a strange business, but it's still a business. And even a massively dysfunctional business does not run the way a drug-addled ex-gamergate incel can concoct in his wildest imaginings. Jus' sayin'

The "Group-owned land" knowledge base article might help. At the risk of repeating stuff you may already know: To own a parcel of Mainland, whether by group or individual the land itself must come into possession of the owner (which generally means buying it from its former owner or from Linden Lab at auction), and that owner must have sufficient "tier" such as the 2,048 m² that comes with a Premium Plus account, or additional amounts paid for monthly. For a group to own land, then, its members must not only arrange for land to come into the group's possession, but also contribute enough tier for the group to be allowed to own all that land. The good part is that, for the trouble, a group gets a 10% "bonus" on contributed tier. For example, if you contribute all your 2048 m² tier to a group, it will have 2048 + 204 = 2252 m² of tier to use on land (which means it can own a 2240 m² parcel because land comes in 16 m² units). As that knowledge base article outlines, there are two different processes that lead to group-owned land: Start with land owned by an individual, then deed it to group while transferring the tier, using "Owner Makes Contribution With Deed", or Group members contribute the tier to the group first, then use "Buy for Group".

Don't fix code samples from Void Singer. They may not be easily digestible but they're worth a good chew. Otherwise… I'm torn. There's value in seeing a variety of styles. But it isn't the easiest on-ramp for those new to LSL.

This pretty much sums up the thread: Unless you're a glutton for punishment or curious to the point of obsession, PBR can wait—and for those who lack either affliction probably should wait lest they trade in Second Life for canasta and cocktails. Meanwhile PBR will get less painful as the tools get more stable, best practices emerge, and there's a body of content to plug into. Perhaps it helps to have done PBR before on some other platform. Or maybe that's a handicap, it's hard to tell based on this thread. I just hope the cognoscenti will remain patient with us masochists as we muddle through. We may not be the idiots you take us for, but there's apparently a tremendous amount to learn. And if this learning requires reading Khronos Group specs or watching YouTube videos, you'll find me in the line for a Temporary Bystander badge.

So you may recall I started down this path earlier, but I eventually talked myself out of it ever being useful, for a couple reasons. One is that the only Environment a script can see into is the one currently in effect on a parcel at a specified altitude. It can get a lot of detail for that EEP, but it's just whatever it is at the moment in the day cycle. It cannot see any Environments in Inventory unless they're applied to the parcel (which makes it useless for many photography applications). A script can set the user-specifiable parameters of a Reflection Probe (ambiance, clip_distance, whether it's a box or sphere, and whether or not it's "dynamic" so avatars can be reflected within the volume). Thing is, the more I played with reflection probes, the more I settle on the view that ambiance should almost always be set to 1.0 (to defeat EEP-specified ambient color, if any) and do everything else with interior lighting. That EEP ambiance is defeated above 1.0, too, and in that range the effect is almost linear: higher numbers simply boost the overall lighting effects, up to 4, by which point everything is pretty bright already, and above 4 the local lighting effects are capped and only brightness from the sky is boosted further (all the way up to 100). Except… and here's the part that's so unintuitive I could think of no way for a HUD to make it palatable: EEP can set a floor (up to 10.0) on your reflection probe's Ambiance setting, with the Environment's "SKY_REFLECTION_PROBE_AMBIANCE" parameter. So if a builder creates a reflection probe for their prefab, say, if it uses an Ambiance setting below 10 (as they almost all will), it can be overridden by the Environment at the customer's site. A HUD could show that happening for a static Environment, but I don't know how the average user would understand and use that.

That wasn't what I was saying, though. All pre-PBR skins and any skins that can ever be developed with existing PBR materials have always and will always look pathetic compared to skins using subsurface scattering (for anything other than still photography, where the effect can be statically faked). But I have no idea how vast the barriers are to getting the capability into SL, or even how "standard" the feature set is.

The avatar is a real problem. I don't know whether mesh avatar makers are going to shift to PBR for their materials appliers while we wait for the Lab to finally decide BoM needs to be augmented with some materials-aware process. Personally, I'm okay with limping along until subsurface scattering is ready for adoption, at which point every skin without it will look Ruth-like in comparison. Lights don't need to contain scripts unless they're supposed to dim or turn on and off on touch, or flicker. I used to use a trick that makes candles and fluorescent lights flicker without a script, but it only looks good at short range, so I've pretty much switched to scripts for that. But definitely, whatever lights one uses, it takes a bunch of work to look good and work right in a setting, but I think the results are a whole lot more interesting for the investment.

I think during this early phase, a lot of lighting environments that are trying to be "PBR friendly" will end up needing to be tweaked a few times before they work well with most PBR content—which is even more of a moving target as creators learn what does and doesn't work with the kind of lighting in which the content most often is seen. We've done all this before: By Cecilia Bleasdale - https://web.archive.org/web/20150227014959/http://swiked.tumblr.com/post/112073818575/guys-please-help-me-is-this-dress-white-and, Fair use, https://en.wikipedia.org/w/index.php?curid=69200610

Control-Shift-1 to open the Statistics Bar, then scroll down and open the Simulator and Time sections, where you get information as documented here: https://wiki.secondlife.com/wiki/Viewerhelp:Statistics#Simulator (Somewhere there must be documentation of the "Scripts Run" percentage, which is the first place I look: if it's somewhere near 100%, the sim is just fine and the problems are elsewhere.) Because you mentioned "yesterday" I'll just note that there was an unusual CloudFlare outage that caused trouble all across the internet (although maybe not the kind you experienced, or at least I didn't see that myself).

(Incidentally, the "timing" I meant was that they apparently disappeared from the management roster between December 25 and January 15, per the article.)

Right. (I know the OP's reference, it's just… gah, we can't respond.) EDIT: Wait. I only knew about the CMO from Inara's blog post, which was just yesterday. Where did it come out a week ago?

For those two, given the timing: I'm guessing Senra and Motown didn't make year-end targets.

At the Concierge meeting just now, Wendi said it's still on for tomorrow (Thursday) at 10, I guess pre-recorded. She left these links in chat:

As of a month or so ago, the Lab's Chief Marketing Officer apparently isn't with the company anymore, which is relevant to this thread because his legacy includes the WelcomeHub. (All I know is what I read in Inara's blog, and I've learned that big management changes in most companies usually mean less than one is tempted to read into them.) That's an interesting question, along with the above discussion of what destinations are and aren't in the viewer's World / "Destinations…" guide. It's certainly possible to point a Shared Media surface to https://secondlife.com/destinations (or to risk Community Exhibition Inception, https://secondlife.com/destinations/discussions ) but Shared Media is a terrible thing to do to a newbie, so that's not really practical. The current WelcomeHub Community Exhibition doesn't really signal the sprawling array of destinations to explore, but it's always a problem how many options to present (the old "paradox of choice"). Need to somehow thread the needle between "Is that all there is?" and never actually getting past a huge exhibition of choices. Maybe they don't need that many more exhibits as long as it's somehow made clear they're just a tiny sample and there's an obvious way to find more to explore to match individual interests. Could be as simple as a sign showing how to open the viewer Destinations to see more, and/or a dialog that opens the Destinations page on the web (assuming their SLURL-teleporting is working correctly, which may be true for newbies until they start installing TPVs). That all assumes the Destination guide (whichever listing) is a good place to start. It's definitely not perfect, and efforts to improve it could be well invested, but it does seem the closest thing to what's needed to augment any number of exhibits at the WelcomeHub. Incidentally, the exhibit builds could use some expert review. I'm guessing Moles do this for each other all the time to make sure what looks good for the original builder will actually work for a newbie in the standard viewer with default configuration. For starters, walk through with RenderVolumeLODFactor set to 1.0 (or the equivalent Preferences setting) to see how close-by everything collapses to convoluted triangles.

and here I wasted all these years learning ventriloquism.

Yeah but is the back of the belt buckle sufficiently detailed? We're competing with triple-A drawers here!

The thing is, we all know with zero doubt that if we have 2K textures, they will be abused. And if we're honest with ourselves, we know they will be mostly abused. So for the handful of trim sheets in a scene that could actually benefit from all 4.2 megapixels in a 2K texture (times usually three of the four possible maps), for those few very special cases we'll all sit around watching the texture console thrash as an incessant stream of the highest possible resolution zipper and button textures clog our downloads. I wish I could worry about draw calls. Most of the time my machine is starved for anything to draw with.

I think you've hit upon the trickiest part of this, and a Linden comment to a recent thread suggests that it's not only practically unknowable but also how it works changes. If the shop really fills the whole parcel, the following suggestion won't help, but otherwise the parcel could be divided, the rental portion deeded to a separate group to absolutely prevent any returns, then use creative encroachment to make both parcels appear much larger than they are, rooting landscaping on one side but linking it so it extends deeply into the other. The trick to preserving the stuff you encroach onto the rental parcel is to give the tenant a role that does NOT include the ability to return objects that DON'T belong to that rental group. But again, this scheme won't help in the case of a store that really needs the extent of the parcel, not just for landscaping.

I'm not sure how literally to take the "open" state of archived jiras, but there have been bugs around touch_start and state changes for a long time, some of which have been fixed, so maybe see if https://github.com/secondlife/jira-archive/issues/2983 can be reproduced. There appears to be a linked issue from just last month that was closed for being a duplicate so I'm guessing it still applies. If so, a touch_end handler might be the simplest workaround.