[Would you use an "attachment-scope Experience"?]

1 minute ago, Modulated said:

Really not sure what you mean by streamlined. The experience is going to have to be explicitly accepted or refused, regardless of dialog  , no? Otherwise it would be a violation of some sort I think.

Yes. Well, I mean we're talking about a change to the functionality, so whatever it is, it's defining what is and isn't a violation, but I'd think it would still require acceptance. There is active discussion right now about how to make that particular permissions dialog less crazy scary with the whole long (but still incomplete) list of obscure possibilities, but yeah, whatever happens with that, I'd suppose it would still apply the first time an experience was enabled by an attachment, too.

By streamlined, I mean that an attachment-scope Experience would be up to the person who enabled the Experience on their avatar, not limited to the landowner (who could nonetheless explicitly disable the Experience on their land). That also means Experiences could be used in creations that are more avatar-oriented and less land-oriented.

I guess for completeness I should mention that when researching this idea I noticed another proposal that would do away with the whole permissions dialog in certain circumstances. I don't believe that's been elevated to "Tracked" status at this point, and I really don't have an opinion one way or another about that one.

[Would you use an "attachment-scope Experience"?]

21 minutes ago, ValKalAstra said:

why something like environment settings need to be on experiences in the first place

That's a good question. I'm not sure whether it would be analogous to llTeleportAgent() which is only available on items owned by the to-be-targeted agent, not including temp attachments, or if Environment management could be on some less constrained permission. (I don't think there's any explicit permissions for it now, kinda like llSitOnTarget().)

Good point about attachment limits. It's something I never think of, but I know it's a real thing, especially with no-mod fitted mesh. (With modifiable fitted mesh, can just link a bunch together in one attachment and let the parts land where they belong.)

[Would you use an "attachment-scope Experience"?]

1 minute ago, Modulated said:

I personally do not like forced experience acceptance for access. I think everyone should experience SL in the way they want to, regardless if the experience is what is preferred by the sim owner. If the experience is mandatory to visit, I refuse and I am not coming back/won't recommend the place to anyone.

That's fine. I'm sure the sim owners realize that some users won't accept the Experience but there's just no point in visiting the region without the Experience enabled, which is when Estate regions can specify those mandatory "Key" Experiences. So it all works out for the best.

But that's not what this is about. There are increasingly common casual uses for Experiences that come up routinely in SL now, but the interface to accepting or denying them is both scary and cumbersome, so I'm looking for ways to streamline that, and feedback on one possible approach.

[Would you use an "attachment-scope Experience"?]

26 minutes ago, Anna Salyx said:

That said, I do like that experiences are land based and not something we carry along with us. (KVP aside, but that feature has been detached from the land if I recall correctly). 

Right, a land-based Experience's KVP is now grid-wide, which is a huge boon to scripting anything that needs to do interregional object-to-object communications, especially broadcast messaging and access to a common data store.

But could you elaborate on why you favor land scope for Experiences, "not something we carry along" (attachment-based)? I'm genuinely interested in whether there's a reason here I should just drop this idea.

Not to argue the point here, but to give another example: I too really like the Experience-enabled props. I'd like to take that one with me so it works on furniture that was designed for its use, even if the furniture owner never enabled it on the land. I encounter that all the time. There are reasons they don't enable the Experience besides just not getting through the About Land interface to make it happen. For one thing, the furniture owner may be a renter, and the landlord may not respond to tenant requests.

Or even—something I never thought of until the previous post—the landowner may not want to let their furniture annoy folks who don't want to see the requests but don't want to block them either. That's really a reason for attachment-scope Experiences: folks who want to use furniture designed for an Experience could carry that ability with them, without the furniture needing to ask others for land-scope permissions. (People who grant those permissions already never see those requests again, but folks who won't grant nor block the permissions must see them all the time.)

[Would you use an "attachment-scope Experience"?]

5 hours ago, graceblakeley said:

Just leave me alone.

Currently there's no way to prevent all Experiences from ever asking a specific resident whether they want to participate, but it certainly doesn't advance my proposal to have users getting annoyed by requests they don't want to see. The Lab is not going to deny everybody else the opportunity to use the Experience feature, so instead would it help if you could choose a preference that suppresses all prompts to participate in any Experience?

Such a preference could (and probably should) be handled local to the viewer, so I wonder if any third party viewers already have a setting to simply ignore all optional Experience-related content. Maybe you could make a feature request for your usual viewer to change that? 

[llGetNotecardLineSync()]

51 minutes ago, Love Zhaoying said:

In case I missed it - does it appear that reading a single notecard line may be enough to cause the rest of the NC to get cached? (My "ready to use" code doesn't care either way, just checking..)

It's enough to get it cached (as is asking for the count of lines) but there's no guarantee it will stay cached for any length of time. It's possible the notecard will be cached to fire the dataserver event and then the region crashes or is restarted before even a single llGetNotecardLineSync can return, or at any time thereafter, so then it'll need to be recached before any -Sync calls can proceed.

Of course it's much more probable that once cached the notecard can be synchronously read to the end, so from a performance standpoint it's a huge win. But still need to handle those NAK exceptions at any time, so the program flow can't be that simple.

[Would you use an "attachment-scope Experience"?]

4 hours ago, Love Zhaoying said:

So perhaps, that could be the "ask" - allow creation of grid-wide Experiences, but tie them to only work if user has Attachments running scripts for that Experience.

I hope that makes more sense than my previous reply LOL!

A few use-cases:

- Grid-Wide Combat Experiences requiring certain brands of HUD

- Grid-Wide Mesh Body Experiences requiring Experience connected HUD

- Grid-Wide Shopping Experiences requiring Shopping HUD

- Grid-Wide Hunts requiring Hunt HUD

I'm not sure what the Experience features would be in these cases other than Combat and other "gaming" now that the game controller interface is almost live and the Pew-Pew Crew meetings are ongoing. But I'm sure something creative could emerge. Honestly, I've been stuck thinking about Experiences as "land scope" so long now I've kinda lost track of my original hopes for them. 

I would just reiterate, though, that if this is presented as grid-scope experiences with an attachment requirement, I think it's doomed. I think it might have some hope of success if pitched as a natural extension of the way attachments already get permissions (and can use them anywhere), just with the extra precaution of explicitly asking for the extended permissions and allowing landowners to disable them if desired.

23 minutes ago, Zalificent Corvinus said:

Listening to you two gabbling at each other suggests you both live in some "head jammed up a compiler's rectum" cloud-cuckoo-land, where you are oblivious to the real SL.

If my imagination were limited to your "real SL" I'd never have logged in past 2006.

[Would you use an "attachment-scope Experience"?]

1 minute ago, Love Zhaoying said:

Can any Tom/Dick/Harry create scripts for any grid-wide Experience?

Well, that's what I mean about rare unicorns: As far as I know, nobody except Lindens and their unindicted co-conspirators have created a grid-scope Experience since that beta closed, about a decade ago. So putting an attachment-enabled Experience feature behind a grid-scope Experience prerequisite would only be useful if they started minting those again, but after all these years of begging, I don't see that happening.

[Would you use an "attachment-scope Experience"?]

1 minute ago, Love Zhaoying said:

I suppose there is not much difference between this and a "grid-wide Experience", except you only participate in the Experience if wearing the attachment..couldn't that distinction just be checked by a script in the Experience?

Not sure I understand. I guess if one were starting from a grid-scope Experience, scripts compiled to that Experience could check that the user is wearing a script compiled to that same Experience (or something), but that's not very reassuring to users who only want to participate in the Experience while wearing the attachment: how can they know all scripts in the Experience enforce such a check on themselves? 

But I could be missing the point. Grid-scope Experiences are such rare unicorns I've never taken them seriously.

[Would you use an "attachment-scope Experience"?]

This seems like a scripting question but not really: scripts wouldn't much change. Rather, it's a user question: Would you be more likely to use an Experience if it were in force only when you wore an attachment that obtained your Experience permissions?

This isn't a big philosophical difference because Experiences can always be enabled and disabled in the simple viewer interface. Even though it's simple, though, it's not something people do very often, so it's easy to forget how simple it is. But I think we could make it even simpler and more "automatic" for users if the Experience permissions were stored in an attachment. An Experience attachment might be worn as part of an outfit, for example, like a role-play HUD or combat meter, etc. We're already accustomed to those attachments taking a whole bunch of permissions (they don't even need to ask) because we know they're only in force while worn.

Unlike those other attachments that just grab permissions without asking, I'd suppose an Experience attachment would still need to explicitly ask for Experience permissions initially. I'd actually want it that way, although that presents an irrationally scarier prospect than it should, with that whole long list of things an Experience script can do. If users were actually presented with the list of (more and different) things RLV can do, they'd be similarly spooked, but I think the details of Experience permissions should remain explicit.

A practical change (and one that would require some server-side work) is that "attachment scope" shouldn't require land-scope enablement, but should comply with land-scope blocking. In practice, I don't recall ever seeing an Experience blocked at the parcel level, but it's an ability landowners should have. On the other hand, landowners shouldn't need to enable all Experiences individual visitors might want to have attached.

One example in a recent Forums thread reminded me that the ability of Experiences to help users effortlessly navigate their personal Environment settings is defeated because they cannot take that Experience with them to locations they may want to photograph or otherwise enjoy with their array of Environments. It can make a big difference, using a tailored UI script instead of wading through a viewer UI made cumbersome because it must support the entire array of use-cases. But scripts cannot help currently because they need Experience permissions to make user-requested Environment changes, and users aren't able to take those permissions with them. That's why I think we need this.

[Firestorm PBR Alpha viewer]

7 minutes ago, AmeliaJ08 said:

Where do you get the new beta? I was talking in the preview group and they told me a beta is out and I should get a notice when logging in... but I don't.

I too never get a notice when logging in, but check the group notices.

(I must have nerfed my group settings or something. Somehow I get announcements from other groups but not this one. Ironically, Firestorm often dredges up group announcements that I already saw ages ago in one of my usual viewers.)

[An issue with scripts]

Works here. Try this in the root of a linkset you don't mind having recolored:

default
{
    touch_start(integer total_number)
    {
        integer link = llDetectedLinkNumber(0);
        llOwnerSay("Touched link: "+llGetLinkName(link));
        llSetLinkColor(link, 
            <llFrand(1.0), llFrand(1.0), llFrand(1.0)>,
            ALL_SIDES);
    }
}

I guess if that doesn't work, try a different region?

or show some code that isn't working?

[Linden lab is charging me over a land i don't own anymore]

16 minutes ago, AmericaHf said:

i checked and there's a next bill date (04-04, thursday) on land holdings, i have 0 meters holdings, i don't know what do... and yes my premium is cancelled.

Okay, sorry, I was checking with an account that has never gone Premium at all, and it didn't have a next bill date, but maybe once you go Premium you get a next bill date forever, even when the bill is zero... which is what I hope you see in the "Total monthly cost" above that bill date. (I don't have any account that used to be Premium but isn't now, so I can't actually confirm that ex-Premium accounts still have "next bill dates" even though they won't be billed, but it sounds plausible.)

So, now, backing up to your original post on March 5th, probably you were billed March 4th for land you held even briefly at any point after February 4th. If instead you're sure you cancelled everything before February 4th, you should definitely contact Billing. (Their phone numbers are here along with links to submit a support case if that's easier.)

[Question about Raycast]

I knew I remembered this came up somewhere fairly recently. This is extracted from chat at the Simulator User Group a few weeks ago (eliding interspersed discussion of swimming):

Quote

[2024/02/13 12:31]  dantia Gothly: I have a question about raycast results, would it be possible to get the texture cords for the area where the ray hit the surface of a face.
[...]
[2024/02/13 12:33]  Leviathan Linden: Getting the texture coords of raycast on the server seems... nigh impossible in general.
[2024/02/13 12:38]  dantia Gothly: it would be like, detectedtouchST but for raycast result
[2024/02/13 12:38]  dantia Gothly: as if I clicked the texture myself with the mouse
[...]
[2024/02/13 12:38]  dantia Gothly: that same result is what im looking for
[2024/02/13 12:38]  Qie Niangao: hmm... how *does* raycast do surface normal? that must be the physics surface?
[...]
[2024/02/13 12:38]  Rider Linden: /me is looking at the doc for cast ray now.
[2024/02/13 12:39]  Vale (thunder.rahja): I believe it looks at the surface of the physics mesh, Qie
[2024/02/13 12:40]  Vale (thunder.rahja): As llCastRay is a function that talks with the physics engine, and the simulator is unaware of the visual mesh of objects
[2024/02/13 12:40]  Rider Linden: It looks as though llCastRay returns a list.  That means we would be able to expand what it returns.
[2024/02/13 12:40]  Qie Niangao: so can't just stretch the texture over the physics surface and get a UV that means anything, I suppose
[2024/02/13 12:40]  Vale (thunder.rahja): Take sculpted prims for example. To the simulator, they are spheres, but the viewer turns them into whatever shape the texture describes.
[2024/02/13 12:40]  Rider Linden: Not sure about being able to send back a UV though.
[2024/02/13 12:41]  dantia Gothly: https://wiki.secondlife.com/wiki/LlDetectedTouchST this returns the vector coords where it was clicked,
[2024/02/13 12:41]  URL Reader HUD: https://wiki.secondlife.com/wiki/LlDetectedTouchST = "<nolink>llDetectedTouchST - Second Life Wiki</nolink>"
[...]
[2024/02/13 12:41]  Qie Niangao: right, with llDetectedTouchUV, the viewer is in the act
[2024/02/13 12:41]  Rider Linden: Oh!  But it change the stride. 😞
[2024/02/13 12:42]  dantia Gothly: yeah and detectedUV was the other one
[2024/02/13 12:42]  Rider Linden: but wait... it takes flags about what to return.
[2024/02/13 12:43]  Vale (thunder.rahja): I've had to troubleshoot a handful of issues related to an object's physics mesh mismatching (and overextending from) the visual mesh in combat sims.
[2024/02/13 12:43]  dantia Gothly: I can write up a canny request, but I just wanted to bounce around here, I can use this kind of raycast function for a lot of cool things, including cool things for weapons in the combat setting.
[...]
[2024/02/13 12:44]  Qie Niangao: Vale, yeah, I get raycast returns from distant Kidd grasses all the time
[2024/02/13 12:44]  Rider Linden: Yes, please write something up so we can kick it around on this end.

So maybe check-in with dantia Gothly (or, if I've just outed an alt, sorry 'bout that!).

 

[What's the buzz, tell me what's a-happening?]

Every time I see the original post quoted, I get a little shiver when I think about "straight talk" "from Brad."

Even before the salacious stuff the thread is presumably about, SL presented some recent personnel challenges that, if I were in his position, would really test my patience. Every day that we don't hear what I've been fearing Brad would say is some reassurance that he won't be saying it… this time around.

[Prim count per resident]

In a quick test with only four prim owners, it sorted them alphanumerically by UUID of the owner.

It's not clear how you'd use this information, though. Seems to me the easiest solution is to divide up this region into a bunch of parcels until they're each safely under 100 rezzing residents. The only other alternative that comes to mind is an exercise in sensor probes that would be unbearably tedious to script (but it wouldn't be too surprising if somebody sufficiently OCD already did a version of that). I suppose a bot could scrape the Object Owners table in About Land, but I'm not super confident that would ever list more than 100 residents either. Maybe somebody has a better idea.

[Using "boolean" (integer [1|0]) return type in logical operation results in Math Error?]

Apparently LSO threw math errors for imaginary results of llPow() and llSqrt().

(… also llSubStringIndex() might prove useful here'bouts.)

[RL to SL scale differential for building RL landmarks]

15 hours ago, Qie Niangao said:

scripts with Experience permissions can do it without being attached

Oops. Forgot how I did this. Experience permissions suffice for calling llSetCameraParams() without error, but I don't think anything actually happens unless the script is attached or the avatar is seated on the scripted object. With Experience permissions, though, the object can llAttachToAvatarTemp or force the avatar to llSitOnLink.

In case it's of interest, I played around with this a bit and found some parameters that seem about as close-in as possible while preserving some minimal context for navigation:

        llSetCameraParams(
            [ CAMERA_ACTIVE, TRUE
            , CAMERA_BEHINDNESS_ANGLE, 1.0 // (0 to 180) degrees
            , CAMERA_BEHINDNESS_LAG, 0.0    // (0 to 3) seconds
            , CAMERA_DISTANCE, 10.0 // ( 0.5 to 10) meters
            , CAMERA_FOCUS_LAG, 0.05    // (0 to 3) seconds
            , CAMERA_FOCUS_LOCKED, FALSE    // (TRUE or FALSE)
            , CAMERA_FOCUS_THRESHOLD, 0.0   // (0 to 4) meters
            , CAMERA_PITCH, 0.0    // (-45 to 80) degrees
            , CAMERA_POSITION_LAG, 0.0  // (0 to 3) seconds
            , CAMERA_POSITION_LOCKED, FALSE // (TRUE or FALSE)
            , CAMERA_POSITION_THRESHOLD, 0.0    // (0 to 4) meters
            , CAMERA_FOCUS_OFFSET, <9.5, 0.1, 0.94> // <-10,-10,-10> to <10,10,10> meters
            ]);

So perhaps some such script could offer to temp-attach only while the avatar is in close quarters, and either detach or clear CAMERA_ACTIVE when they go back outside.

[Why I Don't Like PBR]

The "competition" I'd watch would put the "haters" in an arena from which they can all leave in glory only when they agree on one "standard" PBR-friendly Environment in which all their desired content looks good.

… because I've come to doubt that any such Environment—let alone a folder of them—could ever exist.

Prove me wrong. Double-dog dare ya.

[RL to SL scale differential for building RL landmarks]

I agree that camera location is at least a huge part of why at-scale avatars need scaled-up structures, and inside a structure is where the effect is most pronounced. Just passing through an at-scale doorway will cause the default cam to push through a wall, and that feeling extends to doorways you're not actually walking through at the moment. It's not only height either, because the cam has a way of landing behind a wall that's behind the avatar, so the cam "pushes" all dimensions outward.

Viewers can change the default cam location, and manipulating cam position and focus is very common in vehicles and furniture. The scripted cam functions are normally reserved for attachments and sat-upon things, but scripts with Experience permissions can do it without being attached if that happens to be an option at this site. (I don't remember actually using it for this scale normalization myself, but it seems worth a try.)

[Why I Don't Like PBR]

10 minutes ago, PekeNL said:

Edit: yes I know there's also emission , but that's not always required.

Very rarely, in fact, so I'm irked when people say PBR demands so much more texture acreage than before.

But perhaps other than reflectivity, emissivity is the one quality most nerfed pre-PBR because it was coded in the alpha channel of the diffusemap, with the result that graduated emissivity was simply impossible on partially transparent surfaces. Granted, not a lot of call for that (at least not on dry land) but there was no way to do it at all with Blinn-Phong.

[Lab Gab?]

8 hours ago, Jaylinbridges said:

Has anyone seen a Lab Gab announcement where the participants were not listed in the announcement?  This is very strange. Was LL unsure who would be interviewed (as in available) for the Lab Gab?

I went back and listened to the link Pantera supplied to her recording of the Concierge meeting, and Wendi said the Lab Gab session would include "developers and such" so the plan at the time of the announcement (Feb 21) probably didn't include any big name appearances.

Finding Lab Gab announcements seems to be more difficult than I expected, searching the Blog history. There was one about the WelcomeHub's Community Exhibition opening that ended up being hosted by Strawberry and Patch but I don't see any names on that announcement either. On the other hand, the five SL20B Lab Gab live events were detailed in the omnibus birthday announcement.

[Linden lab is charging me over a land i don't own anymore]

7 minutes ago, AmericaHf said:

 its been exactly 1 month since i cancelled and paid my debts, yes i had paid everything on the past month

I'm not sure exactly the timing here (and you may need to contact Billing to get help), but my guess is that the "exactly 1 month" interval isn't aligned with the fixed monthly billing date, so you were paying for the remainder of the billing cycle after you cancelled. You may be able to confirm this yourself from your dashboard—and you'll want to go there anyway to make sure this isn't going to continue happening!

Maybe first go to the Account Summary page and look at the bottom: is there a "Next bill date"? If not, then presumably you won't be billed again. (If it shows a "Next bill date" then at least the Premium subscription somehow didn't get cancelled.)

Then you may want to check the Account History pages for the past couple months to see what the account billing date was. There's probably a billing record description starting with "Recurring Mainland Fees" somewhere with a date that tells you the end of the billing period for which the charges applied. That means there was land held at some point, however briefly, during the month before that date.

If those records don't answer the question, I may have just misunderstood what you already explained.

[Experience key question]

Wouldn't it depend on whether the application ever had reason to query (or update) the stats independently? (Maybe I'm oversimplifying this application.)

[What's the buzz, tell me what's a-happening?]

59 minutes ago, BilliJo Aldrin said:

You really have to wonder why the offical viewer won’t support  RLV, especially now that LL is willing to admit that s e x exists in second life 😂

It'll be interesting to see if the LUAU (Roblox-flavored LUA) client-side scripting will effectively replace RLV. At first I assumed that any API that's useful for anything would necessarily subsume everything RLV does and more, but I think there may be a way to neuter it so it can't respond to any communications from in-world at all (which would relegate it to glorified UI shortcuts programming).

Interesting times if we can just hold in there.

Speaking of which, for the idle conspiracist, "across the street" has a topic germane to the OP, as does reddit and NWN. I've yet to detect any signal in the noise.