Qie Niangao

In case these are referring to the situation I described in my original post, to reiterate, the problem was not that the different viewer caches interacted in any way but rather that the viewer relied on cached Materials information long after it was no longer valid in the sim. The only relevance of there being another viewer involved at all was that I used that other viewer to make the changes in the sim, unbeknownst to the viewer that had cached an earlier version of those Materials settings. If that was all obvious, sorry for the redundancy.

You know the Mean Girls meme about making fetch happen, right? I only meant the whole Social Casino concept is impossible to sell: it predictably started desolate and subsequently faded. I guess in the SL context, it's parallel to the Lab's predictably doomed "Enterprise" team that M set up under… was it Glen Linden? Just a thing that, no matter how much is invested in making it a success, "it's not going to happen." (To be clear, this is not a critique of the build, which I rather like. It's just in service of such an ill-conceived business idea, which was even forgivable as a kind of trial balloon, but… Oh, fine, I guess there's no telling how eager a fresh crop of Mobile viewer users might be to flush L$s into the void.)

Hmm. I suppose some folks who put up walls would stop doing that if they could instead define their parcel to be a Virtual Private Space and that might help some, but otherwise it's really not what I wanted to achieve with parcel-level derendering. As I understand VPS, it seems like a parcel-scale void-surrounded private island, and I guess I can see some Mainlanders would want that, but my objective was to improve the existing, expansive Mainland experience by offering visitors a somewhat curated view, removing the worst eyesores, the way individuals use derender in their viewers for specific problematic content. Of course maintaining parcel derendering lists could be a burden for large-scale landholdings, but so is everything else about owning a bunch of Mainland.

Oh certainly, the same way EEP has "Use Shared Environment" and all the personal Environment options. The parcel derendering list would just be the "Shared" view of the parcel surroundings, but anyone could travel everywhere and see all the walls and floating skyboxes from every parcel, regardless of what the landowner suggests. But again, if a landowner didn't need to put up the walls to fix the view from their parcel, there'd be a lot fewer walls to derender.

It took me a few readings to understand the "narrow alpha blended border with it's occluded edge" but yeah, if this were my own model, I can see how that would solve the problem. As a one-off, the best compromise I can concoct is essentially a shadow prim on top of the pretty tiled-Material surfaces on those that need the high resolution detail but lack structure-scale occlusion. It's horridly inelegant but actually looks pretty good so far.

That's actually the first thing I'd suggest, too. That and nuking the "social casino". If it really must still exist at all, it really shouldn't be anywhere near the Welcome Hub: it's an embarrassment and its very presence will drive away a significant share of those who encounter it. Has nobody told the Lab to stop trying to make fetch happen?

Right, but so was altitude-specific Windlight until it wasn't: Firestorm (I think; some TPV anyway) started using parcel descriptions to define Windlights for different altitudes… and eventually the Lab built it into parcel properties that could be efficiently and uniformly shared by all viewers. (Granted, the history of EEP had its "troubles", but not because per-parcel viewer tweaking was so difficult.) This could work the same way, except it could need more per-parcel information than a TPV could smuggle into spare data fields without the Lab getting involved. Probably on average less than a unique EEP at each altitude, though. You should have seen the first draft of my post—not that I've completely ruled out a secret conspiracy of land-selling Lindens and their useful idiot viral wall-builders.

Yeah, it can't be completely free, so that reduces its usefulness for the newest residents who must first cross the barrier into putting payment info on file and dropping a few cents into the L$ balance. The hurdle has to be high enough to deter rampant alt/griefer account creation, but low enough to have some appeal for legitimate new users. Does such a number exist? I can't seem to convince myself either way. This is why there are Marketing Departments, huh? If there's any there there, one could imagine a gradual transition to Plus membership which would let them stay indefinitely in their existing home or choose another 512 in Belli or on Mainland. And of course they can always graduate to Premium, a Mainland rental, or Estate living, same as always.

At the risk of pushing this idea further off-topic, I'll choose to interpret "tons on old prim houses in premium area, those with 512 land" as referring to first-gen Linden Homes, and consider there may be something here more beneficial to SL than just sinking those regions into the sea. Something less than Linden Homes, something much less than First Land, something not requiring Premium membership, but something temporary to whet the appetite for having one's own place at bargain-basement entry level pricing. It can't be completely free because everything free is gamed to oblivion, but it's not intended to "pay for itself" from rental income, but rather from longer term conversion to Premium or Estate housing. But would it so undercut the low end of the non-Premium rental market that it would end up losing too much revenue from tier previously paid by those landlords. The almost-free rentals would be very short term, though, like 15 or 30 days, so the temp tenants would need to graduate to some other housing, give up on land (and maybe on SL?), or make a new alt and get a new temp-rental. I can't decide if there could be anything here or not.

This is probably off-topic, but I guess I need some remedial PBR training, having finally used some PBR materials on a complex structure and realizing I don't know "best practices" and I'm a little fuzzy on the tech, too. It starts simple: I want to tile PBR materials on walls and floors. The walls in particular have real 3D features (columns, alcoves, etc.) that should naturally have an occlusive effect. For the life of me, I see no effect of enabling SSAO regardless of viewer or driver settings, so I guess I have to bake that occlusion into the red channel of the metallic-roughness-occlusion map. It's easy enough to do by subtracting the blackness of a greyscale AO-map from whatever occlusion is in the tiled Materials… … so I do that and it looks pretty good, but doing it this way means I have lost the resolution advantage of tiling those source PBR materials: I had to tile them onto a final-resolution image before I could apply the structure-level occlusion, so a 3x3 tiling reduces effective resolution by a factor of nine. Worse, if the same tiled materials are used on different walls with different structural occlusion effects, I have to make a separate high rez material for each of them, a reversion to the download and memory bloat of unique per-face textures. So I went to Scarlett Creative to inspect the two PBR models I found (search aided by highlighting reflection probes 😛 ) and from superficial inspection it appears they, too, use the baked occlusion approach along with other adjustments to the tiled textures. I really hope there's a better way to do this.

Mentor chatbots could be a big win. It's important they make it clear they're chatbots, not some uncanny valley NPCs presenting in the style of orientation role-play "personalities", just dutiful sources of the kinds of information newbies will want, presented however it has been most readily absorbed. The introvert in me would rather talk to a chatbot than to bother a real human mentor, but I'm sure others will find it all too impersonal for a "social" virtual world. The most tricky bit, seems to me, is training data. There's the knowledge base and wiki and forums and whatever chatlogs they've collected from previous mentoring sessions. Problem is, the half-life of truth is pretty short, as SL's tech, interface, and venues evolve.

Okay, I submitted https://feedback.secondlife.com/bug-reports/p/pbr-materials-in-cache-used-long-after-object-has-changed on the theory that I won't be the only one finding this behavior "unexpected" when they encounter it.

How hard could it be to give landowners the ability to de-render specific content outside their parcel for the default view of all visitors to their parcel, rather than each viewer having to specify the de-render list individually? Applying that parcel-specific view could hardly be worse than the massive effects EEP imposes every time we cross parcel borders—which is gated to a minimum of 128 m² parcels, so this could be too, or make it a 512 or 1024 m² gate, or even larger if it's really a concern. It's not only that this would give Mainland more value to its owners by letting them block off ugly walls, but it would also reduce the number of those ugly walls, made unnecessary when whatever they were trying to hide could instead be hidden on command, no prims required. This came up ages ago and as I recall it was rejected because Philip thought it would break continuity of the Mainland experience, with objects vanishing and reappearing as residents crossed parcel borders. As if huge walls contribute to continuity. 🙄 (To be honest, Philip had many bad takes, including portal-phobia and the bizarre notion that nature abhors a hierarchy.)

Just to be clear, I certainly use different cache locations for each viewer which is only prudent—although in this particular case using the same cache might have prevented the problem I'm describing, although I'd still never try it. There's nothing here to suggest a problem with the Firestorm beta; the problem was the Linden viewer was relying on its cache for information I'd never expect it to continue to use long after the objects' actual Materials properties had changed. (My hunch is, though, the same would have happened in the opposite direction too. Pretty unlikely Firestorm devs have gotten 'round to changing how PBR Materials caching works.) I'll probably file a Linden bug report eventually, on the theory that changed PBR Materials are somehow overlooked in determining whether a cache entry is valid. But I'm kinda waiting in case somebody explains that this is all behavior everyone should expect so no need for a bug report.

Yesterday I was trying the Firestorm beta (mostly to see if those devs happened to do anything about my currently most annoying PBR misfeature) and took maybe an hour to tweak some PBR scales and offsets and correct a misapplied metallic-roughness map on a few surfaces. This morning I logged in with the Linden viewer, flew and teleported around other regions for like an hour, teleported back to that build and everything I'd fixed yesterday had reverted completely! They showed the old, pre-edited scales and offsets in the editor, and the wrong metallic-roughness map I'd corrected yesterday. Puzzled and distraught, I logged off and switched back to Firestorm, and everything was un-reverted, my fixes still applied. That's a relief, for sure, but it means the Linden viewer was using cached copies of all that PBR Materials information, which I confirmed by clearing cache and restarting the viewer. Is this caching behavior normal? Would I see the same thing if I tweaked Blinn-Phong textures and switched viewers? I've been doing that for many years and don't think I've ever seen this.

Right, I think that works, and re-reading the OP it may be exactly what's wanted. Somehow instead I understood that the goal was asymmetrical, that one of the parcels, call it "Parcel A", should be able to hear voice from the other, "Parcel B", but that B wouldn't hear voice originating in A.

As @Rowan Amore explained, you can certainly subdivide land (assuming the necessary permissions as you say), and you can assign each to have voice or not, but I'm not sure it's possible to have voice from one parcel go into the other but not vice versa. But I'm no expert on voice. I'm basing this on the way "parcel privacy" is necessarily reciprocal, and that may have nothing to do with how voice works. But even if you can't do it with voice, there may be a workaround, depending on the objective. Maybe the sound sending parcel could just use a parcel audio stream that both parcels are set to hear, with voice handled separately on each parcel. Or that may not be what you had in mind. (Your objects wont come back to you because of subdividing land, as along as ownership remains the same and nobody turns on Auto Return, which should turn off automatically when the land is divided but I always do it manually first anyway, just to be paranoid.)

Suppose we design a new user experience that unintentionally selects for extroverts. Or introverts. So we create one online culture that's all extroverts, and another that's all introverts. These both seem like dystopian Social Psych experiments from the 1960s.

I know everyone here is super well-meaning, but not everyone wants to be greeted by chat when they're first experiencing a game. Some do, and they should have access to mentors / greeters / Torley. Personally, though, if I'd had an oldbie descend upon me when I first arrived, no matter how charming and earnest they may be, I'd have logged out and deleted the app instantly. Newcomers need to feel welcome in their own way of being welcomed, so the environment must first make it as automatic as possible for them to discover and pursue that tailored path. So, no offense to all the good intentions, but I know as a newbie I wouldn't want to be talked to, and I also know if I talked to newbies now I'd be doing nobody any favors. The newbies need to want it, and the people talking to them need to be supremely skilled at it. Now, as far as knowing what's really happening in the welcome hub: Maybe mentors could tell us their personal experiences but I'd much rather see some numbers. Of course that should be the Lab's best guarded secret sauce, the key to their future dominance of all competitors, but… yeah. We all have no objective idea what's really happening, and no practical way of discovering it.

There's no practical way for the Virtual Railway Consortium to do anything about what's available at the Welcome Hub, nor anywhere in Bellisseria for that matter, where the newbies are at the tender mercies of Lindens and Moles. On the "real" SLRR, however, we have free locomotive givers across from major Linden stations, all of which have rez zones. They're ancient and look primitive (emphasis on "prim-") but they're still fun as an introduction to riding the rails and exploring what's involved and what's to see along the right-of-way. Yeah, border crossings are a pain, which is why the VRC scripts basically stop dead before slowly crossing into a new region. There are other, more sophisticated approaches to the problem, but it's something. Also, actual rail excursions rarely involve more than a single locomotive (or handcar, or whatever), with multi-car trains more to exhibit 1337 h4x0r skillz.

I wonder if others have better luck than I do, linking through old jira.secondlife.com URLs. I still get SSO authorization failure at the old jira, but @Inara Pey reports in a recent Modemworld blog post : and honestly, if asked whether I believe Inara or my lying eyes, my money would be on Inara. So, with some luck, YMMV.

Right. Well, at least we can reference the old jira issue in its new github archive location; I don't know if the old public jira issues even exist anymore for Linden internal access, or they're only seeing the ones that were already imported at time of archiving. I do see that internal to those issues as archived on github, text links to old jira issues are actually replaced by URLs linked to their corresponding github archive issues, which makes one place where the navigation works—and suggests they chose that, rather than doing anything clever at jira.secondlife.com. Mostly, we need to know what the Lab's actual process is w.r.t. these old issues. I don't see archived any of the per-issue history other than comments (no status transitions, in particular), so I don't know what we're expected to do about ongoing issues we reported or were tracking.

The Lab archived everything for public access. The archive has the absolute minimum utility you could imagine.

On Friday they announced the completion of archiving the public jira issues to github. I don't see any attempt to redirect public access through https://jira.secondlife.com/ -based URLs to (links within) that github archive, so that's disappointing. Going to be cumbersome navigating from all the links scattered across the wiki, knowledge base, forums, transcripts, and everywhere else jiras were cited for many years. Also, I can't comment on the archived jiras when signed in to my github account. Well, the issues are "archived" so read-only so that's to be expected, except for example two of mine may need some attention: "[BUG-234874] PBR: old "Brightness", "Darkness" bumpmaps haunted", https://github.com/secondlife/jira-archive/issues/11716, seems to be fixed, finally, or at least I'm not seeing it in the current viewer on two prims I'd preserved that showed the effect until at least a couple weeks ago when I last checked. So if that was imported to the Lab's internal jira tracking, it probably should be closed. "[BUG-234655] "SLPlugin.exe has stopped working" only with Linden viewers?", https://github.com/secondlife/jira-archive/issues/11546, has definitely not been fixed (it's astonishingly bad, with modal error windows sometimes interrupting faster than I can bat them away), so if that hasn't been imported and nobody is tracking the issue, I need to open a duplicate in Canny. Those are just the two I personally wanted to check on just this morning, so not even the tiniest tip of this iceberg. The archive is also severely limited for non-Linden use because attachments in archived issues link under https://jira-attachments.secondlife.io/ which we can't access. Anyway, there were thousands of jira issues pending at the time they were archived and the blog post doesn't explain how we can follow up on their current status,which is kinda the whole point of ever having a public bug repository.

The Land Impact is a pretty complicated calculation and that "More info" pop-up gives hints about what's really going on, specifically which of three "weights" is the highest and therefore determining the object's LI. If three brand new, empty, unchanged prims linked together and set Convex Hull score a LI of 6, there's something wrong with that region, but I bet that's not what's happening. If they're scripted, the "Server" weight could be the problem, which seems the most likely here. If their geometry has been changed (like twisting, hollowing, etc.) it could be "Physics"—but not likely with Convex Hull which causes the expected reduction to 3 only by reducing that Physics weight. If "Download" is the weight responsible, I'd be surprised. I think particle emission and texture animation at least should increase Download weight, but I don't know if they do.