RLVa and SL Experiences

[KT Kingsley]

Browsing the release notes for the latest RLVa in the latest release of Firestorm, I came across something about RLV and SL experiences that led me to the debug setting "RLVaExperienceMaturityThreshold: Specifies the minimum maturity an experience has to be before it can interact with RLVa".

Can anyone explain what this is all about? What can I do with a sufficiently mature experience and RLVa that I can't without one?

(Maybe send RLV commands directly using llRegionSayTo?)

[Coffee Pancake]

This prevents G experiences interacting with RLVa, Mature and Adult ones can. It's a literal threshold.

Edited July 26, 2018 by CoffeeDujour

[KT Kingsley]

What I don't get is what interactions I can do with an experience-compiled script and RLVa that I can't do with a not-experience-compiled script and RLVa that needs there to be a threshold in the first place.

[Innula Zenovka]

I'm having difficulty imagining how an experience and RLVa might interact, too.   I mean, I can use an experience to force temp-attach an item, which might be an RLV relay or a collar, or I could use llSitOnLink as an alternative to RLV's force sit to sit my victim in a trap, which then uses RLVa, but I don't quite see how the interaction comes in and what the RLVaExperienceMaturityThreshold does.   

I see, for example, that Code Violet's AvSitter experience is G-rated.   What can't I do with RLVa scripts in objects that also use her experience scripts that I can do with the same scripts in objects using scripts set to an M-Rated experience?

[Lucia Nightfire]

I believe this all came about with the concerns from an RLV developer over the creator of a particularly popular G rated experience offering scripts compiled with said experience, albeit for sale, that can be dropped into any object with the intent of "legit" operation within the intended mission statement of the experience, but could potentially be abused by rogue users to gain access to a wide range of targets, those allowing(participating in) said experience.

It has nothing to do with what you can do with RLV versus Experiences nor if you can use one with the other. It is simply a basic security measure an RLV developer added to counter abuse of RLV users in the scenario listed above.

The original jira filed on this issue was BUG-216454.

There are a few problems with this method though.

The setting is not exposed anywhere and is defaulted with a minimum of Mature.

Most Experiences will be affected by this since they are not auto-grant types like most Linden experiences and the majority of experiences are General rated.

The setting should have probably been made accessible through the Experiences modal.

This method could also be misinterpreted as a desire for RLV to have supremacy over experiences under the guise of security when both platforms have almost equal stigma and equal means of abuse.

I believe if an experience owner distro's scripts compiled with their experience, it is their responsibility to install safeguards against abuse else they risk their experience being shut down.

Experiences have been shut down in the past due to unintentional abuse through distributed scripts.

I'd like to hear further opinions on this and if I am wrong about anything, please tell me.

[ellestones]

my approach to integrating RLV and/or AVSitter with an Experience

i use the Experience KVP to provide LSL-accessible gameplay levels that we can't access in standard groups

for example: A room/space of devices controlled by a sign-in/out board (touch or collide to sign in/out). Sign-in to the board and choose your level. Play on the devices as dom, sub, either. Anyone can join me. Only those I invite, etc. My level is red (full-on adult) or white (neutral PG-ish), etc

scripting-wise I use either RLV, or AvSitter or own custom Experience for the actual play on the devices. I tend not to mix them together in the same device. It can get messy when not careful. I prefer to compartmentalise as often as possible, where ever possible

for AVSitter beyond G, I tend toward using the opensource repository. Customising these scripts as/if needed

edit add: Just to make it clear

1) Person has to join the Experience

2) Person also has to join the room/space experience by signing in to the controller board

this allows different levels of experiences within the Experience

Edited July 27, 2018 by ellestones

[KT Kingsley]

An interesting problem, particularly with all experiences going grid-wide soon (or so I understand). I too don't see this as a particularly good solution.

Presumably the viewer gets some information about an experience when it tries to do something like auto-attach an object for this to work? Which suggests it might be possible to block RLV activity on a per-experience basis. Or maybe that should be allow RLV activity on a per-experience basis. And then I guess you'd have to block any RLV activity from an RLV-blocked-experience-attached object, even when the script actually issuing the RLV commands isn't itself experience compiled.

And if this information isn't already available to the viewer, perhaps someone could try persuading LL to make it so.

[animats]

If it involves whips and chains, it probably should be done through RLV, even if it can be done through the experience system. Conversely, if it's basically benign, use the experience system, not RLVa.

I got a lot of flak when I tried using RLVa to recover from failed region crossings. It's technically possible to recover from avatar/vehicle separation that way. By forcing teleports and sits, avatar and vehicle can be brought back together. I implemented this as an attachment called "Seat Belt". But it upset some people that I was using "kink features". So I switched to a different non-RLVa approach.

[KT Kingsley]

I'd say it's more a case of, if it can't be done without RLV, it has to be done with RLV, and if it can be done without RLV, then it should be done without RLV. If it is to be done at all.

I don't think it really matters whether the objects involved represent whips and chains or anti-aircraft guns.

[Alyona Su]

8 hours ago, KT Kingsley said:

I'd say it's more a case of, if it can't be done without RLV, it has to be done with RLV, and if it can be done without RLV, then it should be done without RLV. If it is to be done at all.

I don't think it really matters whether the objects involved represent whips and chains or anti-aircraft guns.

THIS. Absolutely the best way to view the differences of Experience and RLV. LL will never include RLV in their viewer, I suspect "Experiences" is their answer to that with the funny side-effect being that they compliment each other amazingly well. Though, integrating an Experience function with RLV is just something I can't wrap my mind around, either. I'm sure some twisted-brain will creatively come up with something! Hahahahaha!!!

[Whirly Fizzle]

Here are the 2 relevant commits in the Firestorm code.

https://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/2c1768105a6e

https://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/64a0eb4b4bb1

[Kitty Barnett]

A lot of people already have a hard enough time trusting experiences that there's no reason to make the experience permissions pop-up even scarier by adding that accepting it means you open yourself up to the entirety of what RLV can do. Especially since it only applies to a minority of all the experiences out there. And while I did still consider it, it's pointless: there's no way to store the user's choice alongside their experience since that data resides with LL and people woudldn't trust anything in FS that sends data off to a web service (and you start running into the GDRP realm with that). And even if you could, you don't have information about experiences accepted in the LL viewer or any other non-RLVa viewer or any older viewers. So all in all, allowing per-experience control of whether it can interact with RLV isn't possible.

 

The next step up is maturity level and this one makes some sense from an expected behaviour POV: if PG is "safe" and A is "explicit" then a PG experience shouldn't be able to do anything questionable to you either (hence no RLV). If you're accepting an adult experience then if that strips you naked and chains you to a wall it's at least somewhat defensible. Between that black and white, Mature is the grey area and since there are some M experiences using RLV I decided to settle on that for a middle ground. Personally, as an individual, I'd rather ban the interaction altogether and keep the two separate since that prevents a whole lot of headaches but when it comes to picking defaults it's ultimately the average user's point of view that's relevant.

 

Why make it a debug setting? Because especially with RLVa there's a huge disconnect between what the users on either side of the spectrum want and expect. At the one end you'll have people who turn it on because they had a scripted gadget that uses RLV but they never expect (or want to) to have anything unexpected or anything they did not consent to happen to their avatar. On the opposite side, you have the hardcore restrictions users who want the illusion of having as little control over things as possible. Most people fall somewhere in between so that's what I try to look to when making defaults, and since there are people who need more or less, I generally think at least having the debug settings available for those specific cases so that they can set their specific threshold would be helpful.

 

Moving forward, I was working on a feature (that didn't finish in time for FS' release) that would allow people to pick their point on the spectrum (e.g. Casual / Moderate / Hardcore) and adjust the debug settings accordingly for that group of people and 'RLVaExperienceMaturityThreshold' is one part of that. The reason it's not exposed in the UI is because I can see little reason for it to be, it will be tied to the future user level and those that have a specific preference will know what to change manually on their own. You can/could already block all experiences by disabling "Temporary Attachments" in the menu and in the niche case where you'd want to allow temp attachments but not experiences it's now possible, but requires manually changing the debug setting.

[Callum Meriman]

As the bug is not viewable to mere mortals, can we please have a meaningful synopsis of just why this restriction was needed and what it does. along with it can't be handled through governance instead of yads*? All that is said above is meaningless to me, although the commits suggest you are blocking experience attachments (I don't c++ so can't be 100% sure on that).

I have a hardcore submissive, and I script both RLV and Experiences a lot, so does this mean that I can no longer experience attach my G rated game HUD to people using RLV?

If it's as bad as I think it is... Recall... we only get 1 experience. Mostly we need to make the G so people don't get scared. But if this now means anyone with RLV will be locked out... MEH!

 

*yads = yet another debug setting

Edited July 28, 2018 by Callum Meriman

[Fionalein]

Want some simple user feedpack? If your experience needs RLV you can keep it for yourselves  So why even bother incuding somthing that will make it rejected by a big bunch of users. I already decline group dancers - better save than sorry.

Edited July 28, 2018 by Fionalein

[KT Kingsley]

I still don't get it, it seems.

default
{
    touch_end (integer count)
    {
        llRequestExperiencePermissions (llDetectedKey (0), "");
    }

    experience_permissions (key id)
    {
        llAttachToAvatarTemp (ATTACH_RHAND);
    }

    attach (key id)
    {
        if (id) llOwnerSay ("@setrot:3.14=force");
    }
}

I dropped this script into a prim, compiled it using my own moderate rated experience, fired up an alt, set the alt's RLVaExperienceMaturityThreshold to 3, adult, and had her click the box. The box attached and the RLV command was executed.

I then set the debug setting to 0, never, and tried again. Again, the box attached and the RLV command was executed.

I guess I'm missing something here.

ETA, ok, so I then added my experience to my alt's RLVaBlockedExperiences debug setting, again with no discernible effect. I think I'd better wait for someone who knows what they're doing to explain this to me.

Edited July 28, 2018 by KT Kingsley

[Innula Zenovka]

@Kitty Barnett It would really help me (and, I suspect, several other people) to have an example of expected behaviour when a G-rated experience tries to temp-attach something that then tries to use RLVa.

For example, what is the expected behaviour when I attempt to temp attach an RLV/RLVa relay to an avatar using a G-rated experience?     Should the viewer recognise that the relay was attached by a G-rated experience and ignore any RLV/RLVa commands it tries to issue?

Edited July 28, 2018 by Innula Zenovka

[Kitty Barnett]

1 minute ago, Innula Zenovka said:

@Kitty Barnett It would really help me (and, I suspect, several other people) to have an example of expected behaviour when a G-rated experience tries to temp-attach something that then tries to use RLVa.

For example, what is the expected behaviour when I attempt to temp attach an RLV/RLVa relay to an avatar using a G-rated experience?     Should the viewer recognise that the relay was attached by a G-rated experience and ignore any RLV/RLVa commands it tries to issue?

I've only ever told people that they should not expect experiences and RLVa to work together; the fact that they do was unintentional so there's no contract or promise that things that worked in the past, or work right now, will work that way in the future. As it stands, by default, PG experiences should not ever expect to be able to attach something that then issues RLV commands. At the moment, M & A are ok, but that's not set in stone either.

Like I said, moving forward there will be a way to indicate the kind of "risk" a user is willing to have. At the low end ("Casual") the combination of experiences that attach things that issue RLV commands will simply be outright blocked; in the middle things likely stay as they are and on the "hardcore" end it's just everything with "moderate" being the default. It also depends on whether LL ends up adding things that help with identifying when a script (or the object) is participating in an experience or not. If they don't, and the hacky way I have to find out right now turns out to be unreliable (KT's script works for me, but apparently not for her so) it becomes more likely that experiences would be denied the use of RLV by default unless the user enables it (or chooses hardcore).

[Coffee Pancake]

1 hour ago, Fionalein said:

 I already decline group dancers - better save than sorry.

That's ... kinda silly. Experiences are a whole lot more predictable and controllable that regular permissions, and if someone does abuse one you have both the ability to revoke permissions, a log of everything that happened and a specific abuse report category.

eg. You accept an experience for Bob's danceball and when at Bob's house find yourself randomly sitting on things. You can view the exact cause of the errant actions performed on your avatar and be accurately informed. Revoke the experience and Bob's magical powers go away, file an abuse report and Bob goes away. 

 

Old school permissions present a way to grant permissions to a script, owned or created by literally anyone, with no ability to revoke those permissions or even log what happened and no way for you or LL to resolve a problem. 

eg. You hugged Bob once years ago. Now your avatar randomly does the chicken dance. You have no idea why. Delete your account.

 

An experience is the safer option in that if you are ever "sorry", you still have control and a direct line to the game gods shotgun division.

(The dialog box is smaller and more familiar though, so there is that; which might also explain why so many people are less afraid of randomly granting debt perms - yes that happens).

 

 

[Coffee Pancake]

1 minute ago, Kitty Barnett said:

I've only ever told people that they should not expect experiences and RLVa to work together;

.. and I will go on record as saying I am opposed to RLVa and experiences functioning together at all, with no way to enable it. Job done. 

Be super thankful Kitty is even trying to square this circle.

[Innula Zenovka]

41 minutes ago, Kitty Barnett said:

As it stands, by default, PG experiences should not ever expect to be able to attach something that then issues RLV commands. At the moment, M & A are ok, but that's not set in stone either.

Thanks. Kitty.    That clarifies things a bit, but can I just focus on exactly what should or shouldn't happen?    Am I correct in thinking that the G experience will be able to temp attach something that is scripted to issued RLV commands (since I can't see how the viewer knows that the script might do before the object is attached) but, if the temp-attached object then tries to issue RLV commands, the commands will be ignored if the experience maturity rating is G?

 

Edited July 28, 2018 by Innula Zenovka

[Kitty Barnett]

9 minutes ago, Innula Zenovka said:

Thanks. Kitty.    That clarifies things a bit, but can I just focus on exactly what should or shouldn't happen?    Am I correct in thinking that the G experience will be able to temp attach something that is scripted to issued RLV commands (since I can't see how the viewer knows that the script might do before the object is attached) but, if the temp-attached object then tries to issue RLV commands, the commands will be ignored if the experience maturity rating is G?

Yes, exactly, nothing about the experience is affected in any way. The viewer will simply add the object to the blocked list and not process its RLV commands, for example with KT's script I  see:

[09:15] Object:  failed: @setrot:3.14=force (blocked object)