Qie Niangao

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.

and why would say "Linden Labs couldn't get it working back then" as if it works now?

That's interesting, but I haven't played enough with moving objects to notice that yet. What I have noticed is the (same?) several second re-lighting of the scene when the cam moves enough to confuse the viewer, even if it doesn't actually move outside the reflection probe volume. I've seen this when 1) selecting an object, 2) entering the Appearance editor, or 3) sitting anywhere near the boundaries of the reflection probe. (This is why I've avoided having multiple reflection probe volumes in builds, but that may be superstitious: I can't say I've actually tested whether overlapping probes trigger the same recalculations.)

I realize this is an old thread but it seems to have the relevant background, so here goes: Shouldn't it be possible for a script to get the base color map of a glTF Material applied to a surface, given all the right permissions? I don't mean a base color override, but rather the base color inside the Material. What I had in mind was to use a script to populate the Blinn-Phong diffusemap with the glTF base color map (and same with normalmaps), so I don't have to keep building with both non-PBR and PBR during the transition while some still can't see the PBR content. But it's my understanding that PRIM_RENDER_MATERIAL returns an impenetrable asset from which there's no extracting the component material maps, and PRIM_GLTF_BASE_COLOR returns only the override parameters which will only reveal a texture if it has been overridden from whatever the Material specified internally. First, is this correct? If I really wanted to write and use such a script, while building I'd need to specify override textures for each surface, not let them populate materials I can use throughout a build? And second, if this is how it works, does it make sense that it works this way? or is it yet another instance of IP paranoia holding back the platform? (I suppose I could do it the other way: paint the basecolor texture as diffusemap first, then have a script use it as the basecolor override on the surface, but that's again defeating glTF Materials reuse, and would be a miserable way to build.)

As long as only a handful of SL players disable it, there's no problem, but the whole platform has been held back for over a decade now by ALM being disabled by enough users that creators must cater to those non-ALM users in order to address the market, omitting ALM features (Materials, projected textures, etc.) because more than a handful just can't see them, and instead baking hideous substitutes (fake static lighting and specularity effects). It is absolutely true that on an individual basis, it doesn't matter. At scale, however, it has hurt SL's content and platform viability. We're at a pretty good place now, with those who really want non-ALM ("forward") rendering still able to get it with the Cool VL Viewer, but the vast majority of users will be able to leave all that behind.

Well, the acronym is UUID, for "Universally unique identifier" which gets assigned to every asset uploaded or created in SL. That would include an image (or "texture") you might have handy and want to use for a license plate. Not sure you're suggesting it, but it's a really bad idea to use a real-life license plate in Second Life (least of all your own). Assuming you have an image that's safe to use, it needs to be uploaded if it isn't already (using the "+" menu on the Inventory window), and then right-click the resulting texture in Inventory to copy its UUID. But what you do with that UUID to make it apply to a car in-world is going to be between you and that car. There are surely hundreds, maybe thousands of different cars that might have different ways of painting license plates. (The fact you're starting with a UUID instead of simply applying a texture in the editor suggests you're dealing with a no-modify car, which unfortunately is fairly common in lower-end SL vehicles.)

Yeah, this is all pretty strange. I checked my list of Experiences and they include a bunch "enabled for all residents" including "Experience Squeaky Mole", "Horizons", "Linden Homes", "Linden Realms", "New User Experience", "SL15B", "Social Casino", "Social Island 2013-10", "Styngr" all grid-scope, and the land-scope "London City". For PaleoQuest, though, they're using an ordinary experience, "PQ2015", not enabled for all residents. Hence the scary dialog for portal access, I guess. Maybe this is all still part of what Quartz meant by the "fix… in QA at the moment" so maybe the WelcomeHub portals eventually won't need the scary permissions dialog.

Honest question from a committed non-gamer: What would new users of the mobile viewer expect of SL's embedded games such as Paleoquest? It's possible these games could hurt retention more than help, as I suspect the "social casino" does, and whatever that "skilled gaming" mess is—I felt dirty just camming into it, and I'm not even joking. But new users may all come from a sports betting background for all I know, and the successor to Candy Crush may threaten to take their firstborn.

(Just in passing: the SMS network is likely to survive EMP more intact than most communications because it's based on a messaging system from the 1970s. In contrast, anything that relies on GPS will be toast. That's not to say anybody should use SMS for authentication—or much of anything else, for that matter.)

Oh noes! Now my monitor is much too fast for YouTube!

"Sensible" is so subjective, though, when the rules are complex beyond human comprehension. When the results are intuitive, nobody celebrates. When there's an unhappy surprise, it's a conspiracy. Or a wrathful god. Or hallucinating AI.

In a situation more analogous to the one @Aishagain mentions, where manipulating an already-rezzed object causes Land Impact to blow up so the simulator has no choice but to remove some existing content (as opposed to stopping it from rezzing in the first place), something happened this past week that pleasantly surprised me. It ripped the thing I was editing right out of the editor to return it, rather than protecting it as a "selected" object and returning some other item from elsewhere on the land. Pretty sure I've seen that other behavior at some point in the past. That may have been a change in the logic or just a happy alignment of the Fickle Forty-Seven Factors of Fate, but it's sure a lot easier to find an empty sandbox to re-rez and debug the culprit itself than to track down where to restore a randomly selected victim.

Maybe in some categories but overall… I think that group far exceeds "very small". On the other hand, I'm happy to say I've had pretty consistently pleasant experiences with creators who have Marketplace presences in addition to in-world stores, but I absolutely cannot say the same of those who have only Marketplace stores. Maybe there aren't as many of the Marketplace-only merchants as I experience because I never actually buy from Marketplace if I can find the item at the creator's in-world store (why give the Lab a commission for an overall miserable shopping experience?) so my actual Marketplace purchases are disproportionately those who offer no choice. I don't have experience with furry wares so that might be an exception, but I've had quite disappointing results with full perm items bought on Marketplace and now avoid it if there's any practical alternative. Even with in-world stores it's not enough to only have such items in vendors without being able to rez a copy and judge its LOD behavior directly, so full-perm mesh… maybe there are some reputable suppliers I haven't found, but just tick the full perm boxes, do a search, and see what you get. It won't be pretty.

Just mute the merchant and get on with Second Life. That merchant making a "report" is like peeing in black pants: they'd get a warm feeling but nobody notices—and they know that perfectly well but think they can use the threat to extort a change of review. Ideally your partner will learn that Marketplace is mostly a den of thieves and move on to dealing with real creators at real shops and events. Leaving Marketplace reviews is mostly a fool's errand (especially if the merchant has no in-world store).

No idea what those products are or what they do, but I probably wouldn't invest too much effort in emulating it because there's a new feature coming soon that should make it obsolete. This cribbed from Inara Pey's indispensable Modemworld blog (emphasis mine) : I guess that assumes you can seat the to-be-hidden avatar. And I presume it doesn't hide the nametag (customarily a griefer exclusive).

Not exactly, but I was going to suggest anyway: If a notecard changes, its key changes, so the changed() event can check the current notecard keys in inventory against their keys the last time they were read to determine which if any of them were responsible for triggering this particular changed() event. (I'm generally skeptical of multi-state scripts unless there are advantages to having only some events active only some of the time—but as a learning experience, go for it!)

This AI-based virtual world Companion and confidante would be really challenging to get right, but ultimately vastly rewarding, and not only for Second Life. Let's take it as a given that it's an opt-in, on-demand thing. When it's in the way, just tell it to scram and it's gone until you ask for it back or it detects and very discretely suggests it might be useful. And assume it has some trustworthy privacy agreement so folks can share any or all of their in-world excursions with the Companion without feeling embarrassed or afraid it'll tattle on them. Unlike a Mentor, there's nothing to prevent the AI Companion from seeing into the user's viewer, for viewers and users that choose to share, just like sharing a desktop for remote troubleshooting. (I suppose a Mentor could get that, too, but that would be asking a tremendous amount of them.) Come to think of it, never mind the newbies: I want one of these Companions for myself, preferably one that could suggest a better strategy for managing Inventory and critique my Adult role-play. There's a business here, I'm sure of it! __________ *That probably sounds scary, but every login session already can be logged by the Lab to whatever level they want; it's what they do with that information that matters.

I don't think so. This sounded way more elaborate than anything I've seen happen, so I had to get in-world to try it, and I can't figure out a way to make it happen: it just blocks rezzing by the owner if it would overflow the parcel's Land Impact, even if more than enough of that excess is from prims owned by others, not set to the land group, that would be autoreturned eventually anyway. (That's on individually owned land, and rezzing directly from inventory. If there's some other situation involved, I can probably set up to try that, too.)

I may have made it sound more similar than it probably is in reality. It happened that I used two different viewers, so that sorta had to be mentioned in case it was actually relevant, but I'm pretty sure it wasn't. Somehow it's possible for PBR viewers to be oblivious to external changes in rezzed PBR materials which they have cached. I don't think it matters how those changes were made, as long as the very act of making the change didn't update that cache. Yesterday Dan Linden updated the Canny report to set it "tracked" and add that it was linked to an existing internal report of the same bug that he didn't think was fixed yet. That news is a relief that others have seen it so it wasn't some really weird, irreproducible thing I did to make it happen. (I'm a little worried that we may have lost the ability to see internally reported bugs, which were a large part of the old jira, now that the Lab still has jira and we don't… but maybe this case was an artefact of the transition.)

"I am your father!" cried he-"Young Rip Van Winkle once-old Rip Van Winkle now--Does nobody know poor Rip Van Winkle!"

Uh oh. Is there a Monty monkey attached?