Jump to content

Qie Niangao

Advisor
  • Posts

    13,368
  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. 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.
  2. and why would say "Linden Labs couldn't get it working back then" as if it works now?
  3. 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.)
  4. 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.)
  5. 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.
  6. 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.)
  7. 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.
  8. 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.
  9. (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.)
  10. Oh noes! Now my monitor is much too fast for YouTube!
  11. "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.
  12. 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.
  13. 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.
  14. 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).
  15. 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).
  16. 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!)
  17. 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.
  18. 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.)
  19. 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.)
  20. "I am your father!" cried he-"Young Rip Van Winkle once-old Rip Van Winkle now--Does nobody know poor Rip Van Winkle!"
  21. Uh oh. Is there a Monty monkey attached?
  22. After pondering this for a really long time, I'm pretty sure we're just wired so differently we're mutually unable to understand the other's position. (Practically, it probably makes no difference because it's unlikely the Lab (or TPVs) will invest the development effort, up to their eyeballs in PBR, game controllers, and whatever they expose to LUA. So it wouldn't get built anyway if I were to resubmit this decades-dormant idea. Although I might, we'll see.) Part of what I don't understand is who's ox would be gored by parcel derendering: the visitor wanting to see the optionally masked content, or the neighbor with the content masked by visitors who've enabled the option. For it to be the visitor, they'd need to have enabled the option and forgotten it's enabled. Visitors who perceive that as a risk could simply never enable the option, analogous to never accepting Experiences or sticking with their own private EEP. So for this to be a problem, the visitor must want to enable the option sometimes and then forget to disable it. But they don't even have the option now—the very option they must sometimes want enabled—so I really can't see how they lose something by being offered that option they wanted. In the scope of things landowners can do to visitors on their parcel, offering an option they might have forgotten they'd enabled seems pretty innocuous. Besides exotic stuff such as Environments and Experiences, a landowner can actually teleport a visitor home, off the parcel's entire region, with or without warning or explanation. I'd never suggest any landowner ever do such a thing, but there are those who think it can be justified. So if not the visitor, maybe it's the neighbor who'd be done wrong. But here again, I don't see how the neighbor would be worse off from this option compared to things a landowner can already do. Landowners can (and often do) put up a wall hiding that neighbor's content, likely the same content they'd set their parcel to derender. The wall is different because the neighbor can see the wall while standing on their own parcel, so they know it's hiding their content. More likely, though, the neighbor is bothered by the view of the landowner's wall from the neighbor's own parcel, more than how some of their content may be blocked when viewed from another parcel. Still, it's true that a derendering option would change the view of the neighbor's parcel without that neighbor seeing it (unless they go and view it from the landowner's parcel). But a landowner already can do surreptitious EEP to the neighbor's content; for fun, I just did this to my Belli neighbor's houseboat: If I left it that way, they'd never know unless they came over to my parcel and looked back. Would the neighbor be justified in taking offense that I chose to add EEP content to my parcel that interacts with theirs when viewed at certain angles from my parcel? Again, I don't think so, especially compared to my erecting a wall. And walls is what the option is mostly about: If a landowner can hide content they don't want to see from their own land without building a wall, I think a lot fewer walls will get built, which makes a better view from both sides, and from everywhere else, especially including other nearby landowners and those just passing through the area. That's why I think this would make a better Mainland.
  23. I'd start with https://avsitter.github.io/avsitter2_prop.html AVsitter props can be used without the multi-sitting/animation system, but if the objective is to have them disappear when the sitter stands up, it's probably easiest to just use the seating stuff too. Setting it up based on examples isn't exactly scripting but it's a bit of a discipline unto itself. (The source for the AVsitter scripts themselves is all free on github or grab a copy from somebody who has one already.)
  24. Yeah, I think this whole discussion of needing AO at object-scale in addition to material-scale is heresy, but it's already in the suggestion box: If SSAO did what I thought it was supposed to, it would do all this automatically. As it stands, I'm really not sure it's doing anything at all.
  25. That might be one option, and TPVs could feasibly do that much themselves, reading the parcel description as they did for altitude-specific Windlight and doing whatever rendering magic it would take to suppress out-of-parcel items. I assume, though, it would actually be easier to derender a tractable list of specific items if there were some way of communicating that list to viewers that already know how to derender a tractable list of specific items. I'm afraid I'd much prefer keeping most of the environment intact, just suppressing the parcel-surrounding walls, the low-hanging skyboxes, etc. Personally, I'm not looking for that private space—it's not as if that's unachievable if I did want it—rather I just want a better Mainland.
×
×
  • Create New...