Qie Niangao

No, I just edited non-physical sat-upon assemblies around as if they were vehicles. I suppose that might be worth testing.

Yeah, I was surprised, too, and wonder if it used to behave differently. Also, it wouldn't hurt if somebody else replicated the results. I used a couple small parcels (for the limited region capacity) directly across a region border and of course it's always possible something specific makes them behave as they did.

I played with this a bit and it's weirder than I expected. A sat-upon object's Land Impact actually applies to the parcel's total land impact right away, when it enters the parcel. If that puts the parcel over its owner's region capacity, one of two things will happen: If it entered the parcel from the same region, it will stay and About Land notes how many "will be deleted" to get back under the limit. While over the limit, it's impossible to rez anything on the parcel. When the seated avatar stands, the sat-upon object is returned immediately. If it entered from an adjacent region, the sitter will be unseated and the object immediately returned. At least that's what it looks like in my testing. I thought I found an edge case where it's possible to enter from another region and have it behave like #1 instead of #2, but I can't figure out how to repeat that. Anyway, the point is the current behavior means the parcel's land impact is affected right away and will prevent rezzing beyond the diminished available capacity.

The way I was reading that, the sorcery was the OP's proposed "let them stand up" approach to exempting vehicles from auto-return while the driver has stood up and is tuning the carburetor etc., not the way the world works now. Yeah, I've done that too, usually making it turn Temporary when I stand, but it's not infallible. If it gets trapped on no-script land without auto-return, it'll be stuck forever unless it's Temporary from the start but then it'll poof the instant the driver stands.

I realize we'll still be able to break the laws of physics and bend optics to our whimsy, but there's something a little disconcerting about the paintbrush being subsumed by the camera (again). But meh, we should enjoy these fleeting days until transformers displace imagination completely. A little more about the Mainland EEP problem. That first step, "Use Region Settings" works fine. (Well, it replicates the region settings, which suck, but it does that part right.) The problem arises when customizing that day cycle at any level—or even just opening "Customize" and saving it to the parcel unchanged: It changes. I haven't compared all the llGetEnvironment parameters nor the whole cycle, but I know the Ambient Color (a.k.a. SKY_COLOR) differs a lot, along with the sun angles (because shadows move when entering from Linden land). This happens in pre-PBR viewers, too, so all the fussing from PBR viewers about non-HDR Environment isn't what's causing the problem. (I guess the unwanted "customization" would be considered "not as PBR" because its Ambient Color is much brighter and pretty saturated at sunrise and sunset. But the problem long antedates the start of the PBR project.) I'd submit a Canny ticket but I've been assuming all this will change at some point.

Not sure if I was unclear or just more off-topic than usual, but what I was complaining about was a problem long before the PBR viewer: the Environment you get with "Use Region Settings" is not the Environment used on Linden protected land. They're both quite dim, but the Linden land setting is even dimmer, regardless of viewer. That's not ideal for private land adjacent Linden land when trying to blend in as seamlessly as possible. I suppose we could bribe a Mole to actually run the comparison. I could see if there are differences among the parameters exposed to llGetEnvironment, I guess.

Yes. But also, as much as we users may keep up, the accumulated platform "evolutions" have made it just crazy complicated for new users even when the changes themselves are simplifications. Eventually they'll need to know what "BOM" means and why it's a thing, and which appearance sliders work and which don't, and why there are heads and bodies and *system* heads and bodies, and alpha masks and alpha slices and hair and hairbases (some system and some EvoX) and shoes as footwear and shoes as height adjusters… and bumpmaps and normalmaps and PBR glTF normalmaps and and and. No idea what to do about it but an ever growing learning curve is a barrier.

This is a problem on Mainland where we're up against region default Environments on Linden land that are not actually what you get with "Use Region Settings" in About Land / Environment, neither of which were great even before PBR. I don't know if we should expect these ever to get repaired, unless maybe when some Materials get spread over the terrain (eventually, we hope). That's annoying because I have a number of open-to-the-public parcels between Linden water and a Linden road or rail, so having distinct EEP settings on my ground level only disrupts the traveler's experience.

Thanks, this is already a big help!

Not only that. They won't see it, either. Personally, I'd much rather the whole thing go away than share content from the Lab's grid with any other servers.

Do you happen to have some of these saved and could share? All I know about are: the Environmental Enhancement Project ("How to EEP") wiki page the Environment Editor knowledge base article which are generally better than nothing, but too superficial to really understand what all needs to change to make EEPs "compliant" with PBR. There's some additional information in the scripting wiki for llGetEnvironment(), but it's assuming "facts not in evidence", for example: Like… and this makes sense because…? Just try searching the Knowledge Base for "HDR". The alternative is dipping into Content Creation User Group transcripts that assume so much history, like: It may as well be in Greek. So I'm really hoping there are pages out there I'm just not finding. Somehow EEP creators are making PBR versions of their previous Environments, but how did they know what to do? Folks wanting to create (or migrate) their own Environments need a clue.

Wish the Forums Cartel were a little more… relevant. It wouldn't hurt if a broader sampling of residents got involved in the forums, and this might be an opportunity. I can think of several "communities" for whom more engagement with new residents might be mutually beneficial. /me reviews group list

Hmm. Now that you mention it, I see a region at the north end of the Boystown cluster, "BT SOCIAL", that appears to be Moderate-rated. (never been, no idea what's there or why, just found it on the map)

Speaking of PoC, anybody remember the "Second Life Community Pages"? The first was "Black Culture in Second Life" (announced in March 2022) … and then there was the LGBTQ+ Community Page (announced in July 2022) … which were to be the first of many to be indexed on a grand unified Community page that still has just those two entries. Not to discourage this new Exhibition attempt, but the half-life of the Lab's "community"-branded initiatives seems pretty short.

Wow, this is either bringing back ancient memories or creating false ones. I think I recall that at first the region where my First Land was located had a tiny, literally Governor-owned parcel in the middle, and then it went away at some point. Was that a real thing?

I snarfed the luminenceHack from jira, before they (temporarily now, soon permanently) disabled logins, and have been using it when I feed llGetEnvironment colors to a simple listener HUD (now that rezzed-in-world fullbright doesn't preserve color anymore). But for non-black Ambient Color EEP settings (like starting from "Use Region Settings"), that fade_color sure does not look like the ambient lighting I see in the environment. But yeah, with the Environment's Ambient Color set to black, there's much less involved in setting a reflection probe's Ambiance value. I guess the full range would be more or less linear that way, inasmuch as the 0-1 setting is practically a no-op, but… is there some reference I should read that explains how the Ambient Color setting is now basically obsolete with PBR? It really does make a tremendous difference, enough that now I guess there's not much value in continuing this project. But if Ambient Color shouldn't be used anymore, somehow every landowner (and any other EEP user) needs to get the memo. This PBR migration is turning out to be much more disruptive than I anticipated. When I read this in that Marketplace description: I got a sinking feeling in the pit of my stomach. I'm really gonna need to find a different hobby.

It's not obvious to me how SL's "adult content" is best represented for newcomers. Historically, there's been the perfect opposite of "community" associated with adult stuff in SL. (The origin stories of "Mosh South" and "Vortex Adult Sandbox" regions make Game of Thrones look like a tea party.) SL Adult content is more an industry than a community, really. Boystown is Adult, but doesn't it also play a big role in Second Pride?* and generally promoting a welcoming environment for an important demographic in SL, some of whom face a very unwelcoming RL environment. They're not unique in that, but they may be especially equipped to engage at a Community Exhibition. If the Community Exhibition is intended to help retain a potential wave of new mobile users, that's cool. The Lab probably should also separately show that Adult content is acceptable here, neither appearing to sweep it under the rug nor force it in the face of those with other interests. As-is, newbies don't have trouble finding it, but maybe let them see it's not all about launching prim genitals at talking heads. ______________ *That's my impression, but I could be completely wrong. I'm gay, have been in SL a long time, and seen a few Second Prides, but have always taken the luxury of not paying much attention.

Now that you mention it… assuming a region doesn't use Telehub routing, and the destination parcel doesn't use Landing Point routing, why wouldn't the "just passing through" bots always choose, like, 4000m where only scripts would notice? In fact some do, but others pop in at ground level; why would they ever choose that unless they're advertising their existence? (By "destination parcel" I mean the parcel at the X,Y location the bots specify for teleporting in, or presumably 128,128 if they only specify the region.)

Not sure what data is a concern here. If the worry is that visitors want to keep secret that they've been to your region, then yeah, bots could collect that data. Thing is, most of the grid—including all Linden-owned land—is wide open to bots. I suppose there might be some appeal to being one place visitors can hide from self-identified bot data collectors, but unless those visitors never leave, they'll be "scraped"… and it's ineffective "hiding" anyway because a bot that doesn't declare itself a scripted agent won't be detected. So banning bots from a region won't hide the visitor's choice of mesh body (for example) when they visit the next region, and won't hide their whereabouts from stalkers willing to use undeclared bots. On the other hand, if they're just a pest, popping in where they don't belong at just the wrong moments: ban 'em. You could ask the bot-runners to relocate visits, but one region probably doesn't matter much to their data collection project.

Just in passing, and I don't know the quantitative details: when introduced, the llReturnObjectsBy*() functions were said to be tightly throttled, not intended for broad anti-griefer use. They'd be fine for this application, but the auto-return function may also be needed to tidy up after griefers. (Slightly tricky to enable on group-deeded land: script must be group-deeded too, and obtain PERMISSION_RETURN_OBJECTS from a group owner.)

They may be keeping options open, or hedging about current non-LRU behavior that's not so simply expressed… such as bugs:

Yeah, that part is a bit truncated, but it's referred to in the quotes: [2024/01/30 12:20] Lucy daughter of the Devil (lucia.nightfire): probably why Wulf found the EOF bug before me, heh [2024/01/30 12:20] Rider Linden: Except for now that I broke it... (that will be fixed before it rolls.) The EOF-related confusion I mentioned, however, was whether the Sync version ever returned EOF at all; there may have been some version of the wiki page that omitted that.

llGetNotecardLineSync discussion at the Simulator User group first cleared up some confusion about the fact it returns EOF, then… well, here's a lightly edited hunk of transcript: What I take away from all this is: we need to handle NAKs every time (no surprise) it may not be worth synchronous retries outside the dataserver() handler, especially for large notecards recent success correlates (but imperfectly) with continuing success: if it's cached in one frame, it's (only) probably still cached in the next the more notecards a region reads, the sooner one will expire from cache after use if the region restarts and you're likely to read a specific notecard soon, maybe pre-heat the cache with an async read (ignoring the results) to improve hit rate on the next sync read

I avoid area search as much as possible. If you use Build / Pathfinding / Region Objects you can sort the results by Distance to make it easy to find, then click the line to select it, and use "Take" (if it weren't a gacha item, you could choose "Take copy" too). That window should work in any viewer, for objects you own or otherwise can move, within the region.

Over the past week or so I've spent a ridiculous amount of time trying to make sense of how the reflection probe Ambiance setting affects different EEP-specified lighting qualities within the reflection probe volume. I'm not even talking about subtle color balancing here, just which qualities even matter. Some observations: As far as I can tell, cloud color doesn't seem to have any effect on ambient lighting anywhere, within or outside a reflection probe. (It definitely changes the sky, but I can't detect any discernable effect on the color of ambient lighting, even if it's fully saturated and every other EEP quality is grey. Maybe at some sun elevations something subtle happens, but I can't really see the cloud color influencing it.) The description of fade_color, "the current color of the light emitted from the dominant light source" sounds good, but I just don't see that color in the ambient lighting. With a black SKY_AMBIENT, that "Environment Ambient" is pretty dark and nearly monochromatic, so the best I can find for approximating Environment Ambient seems to be SKY_LIGHT total_ambient. At reflection probe ambiances between 1 and 4, luminance of all other ambient lighting is boosted, excluding that "Environment Ambient" component completely, but including local lighting. Here what I'm seeing is mostly SKY_SUN sun_color. Above 4, local lighting is washed out by ever higher luminance attributable to "indirect lighting received from the sky" according to the wiki (which still seems mostly sun_color for what little chroma is visible). There are so many parameters that in combination might affect ambient lighting, but I think I'll just give up and use total_ambient for the zero-ended swatch, and sun_color for a band along the bottom of the light grey "indirect radiance" triangle, maybe a gradient up to that upper right triangle that can be bright white and labeled "sky only". The immediate EEP setting isn't necessarily where the probe will be used anyway (the user may need to tweak over a wide range of Environments)—and in many Environments, the different ambient light sources may not be all that distinct anyway, so I think I'm well past the point of diminishing returns with picking swatch colors. Oh, I should respond: yeah, these ranges are intentionally non-linear. This number is nothing like a ratio scale of measurement and is only piecewise ordinal, even. The change in the range from 0 to 1 is usually more extreme than the whole rest of the scale, but there's a qualitative difference in how the other two ranges behave so I think they warrant being shown as distinct.