Add RLV Support | Voters

Add RLV Support

planned

Signal Linden

Proposal: Add Support for the Restrained Love Viewer API (RLVa) to the Official Second Life Viewer

Summary

This proposal advocates for integrating support for the Restrained Love Viewer API (RLVa) into the official Second Life viewer. RLVa is widely used in Second Life to enable enhanced interactive experiences, offering greater flexibility in avatar control, inventory management, and scripted interactions.

Why?

A significant amount of content in Second Life relies on RLVa functionality to provide immersive and interactive experiences. Currently, users must rely on third-party viewers to access this functionality. By incorporating RLVa support into the official viewer, we can:

Improve feature parity with popular third-party viewers.
Reduce fragmentation in the Second Life user experience.
Enhance support for interactive games, building utilities, and scripted experiences.
Provide a more consistent and reliable implementation of RLVa.

References

RLVa Protocol Documentation

A week ago

Angelina Sinclair

I prefer Marine's original RLV to Kitty's alternative RLVa design. Marine was the one who invent RLV in the first place. It is thanks to Marine and her business that RLV has even come this far. Any decent coder could invent an API for scripts in their own personal viewer, but it took a successful business to create a community that loved RLV and regularly uses it. She then opened up RLV scripting to the public, allowing other creators to invent their own devices using her system. Is it perfect? No.
Yet to claim it belongs to the community without acknowledging she created it first does a disservice to all future creators who may invent something that becomes mainstream in the future.
Marine should be given significant credit and her original ideas should be implemented first while Kitty and her contributions should still be acknowledged but added at a later date.

Darien Caldwell

Angelina Sinclair The problem is RLV has a very bad license. It made it unusable for almost all Third Party Viewer developers. that's why RLVa was created.

Angelina Sinclair

Darien Caldwell Kokua viewer seems to handle it fine. I understand RLV is not an API that can be easily plug in and out of other viewers that have re-written LL's code. However RLV is built within LL's more recent viewers. So I would think it be easier to incorporate.

Unless their plans are something else like using RLV to expand Experiences or add lsl functions then it wouldn't matter which version they use.

Zalificent Corvinus

Angelina Sinclair
The goal appears to be to lure users back to the LL Fail-Viewer from the TPV's.
The majority of TPV using RLV fans ACTUALLY use RLVa, so using RLV basically won't work., that's why they suggested using RLVa.

Kristy Aurelia

Angelina Sinclair What exactly does RLV do better than RLVa? I make RLVa items myself, and I see RLVa as being the superior - it has more features, and the only real difference is just

@setsphere

which again has more features, and works better in viewer source code too. Note: I have only used Firestorm and Alchemy as my viewers and never tried the RLV viewer.

Angelina Sinclair

Darien Caldwell I believe the problem was how it was coded, hooks all over the viewer code verse isolated like in RLVa.

The way RLV is implemented works fine for LL's viewer but not third party viewers. However if it is hardcoded into LL's viewer then third parties will eventually have it in their viewer anyway.

Angelina Sinclair

Zalificent Corvinus The majority of RLVa fans use firestorm. They don't care which RLV version is used so long as their toys work.
LL will always promote their own viewer before anyone else's. That should be a given. 
They need to decide which of the two is easier to  read the code, understand it, modify as they like, then implement it. I believe RLV fits that bill better.

Angelina Sinclair

Kristy Aurelia they are both essentially the same thing. The difference is how they are coded into viewer. Sure Kitty added additional functions but the documentation for that is scattered. 
Kitty also made things confusing with the light spheres by implementing her own version which isn't as effective in being restrictive like the original. You can see far further than you should in the darkness and can glitch through it a number if way to see people and things which break immersion. On top of that some of get code involves blocking people's able to use lindens as they like. That's a very niche and scary feature to many folks outside of bdsm. 
So superior is subjective here.

Kristy Aurelia

Angelina Sinclair Okay, so, it doesn't matter then. each viewer has its own code, a lot of the code is also being changed and updated for integration to LL viewer (I've actually talked to Kitty and she's the one actually working on this feature, not LL themselves). if RLVa is the main spec, then any RLV viewer just needs to a small change to work with the

@setspehre

command instead of

@camdrawmax

, how it achieves that in code, doesn't matter. Think of it this way - at the moment each viewer add their own code for all of the RLV/a functionality, if LL viewer provides RLVa code, RLVa viewers just take that code as is, and RLV viewers do the same but replace a small portion of it instead. So instead

LL viewer + 100% RLV/a code = RLV/a capable viewer

, you get

LL viewer - 1% RLVa Code + 1% RLV Code = RLV capable viewer

Also, this gives an opportunity to look into how the fog works since LL will have to approve the code - they might even have suggestions of better ways of doing it considering the PBR changed a lot of rendering stuff. If you mean the thing where you can see the alpha glitch on hair and such, I can have a chat with Kitty and suggest a fix.

Kitty Barnett

Angelina Sinclair Please read Marine's comment on GitHub @ https://github.com/secondlife/viewer/issues/3700#issuecomment-2708749462 . The relevant bit is "I'm all for adding RLV functionality to the official SL viewer, and I don't really care who implements them (as long as it's not me)" but please read her full post (or the whole discussion there for that matter).
You clearly have an opinon and preference and that's fine. Marine and me are different people and my intention for RLVa was to make RLV more accessible to the masses by making it feel less intrusive when not in use, or when used casually (try and recall what guessing attachment points or setting up your shared folders was like 16 years ago), which has certainly worked out. Some people feel that something was lost along the way and that's fine, I can see and understand that point of view but like I mention on the GitHub issue, a lot of people use RLVa now for a whole lot of different reasons and that needs to be balanced out ().
I don't think anyone at any point has tried to marginalize what she has done, and if you read her comment you'll see that LL talked to both of us.
At the same time, RLV has to belong to the community because it will not work or survive in a recognizable shape if it doesn't. I've been trying to open things up and hold office hours, and discuss future proposals publically on GitHub but so far the result of that is getting overwhelmed by people who want to water things down to a degree that I suspect is not acceptable to you and many others and if they are the only voices that LL hears, then we either loose RLV as it exists today, or create an incompatible hybrid. So there needs to be a community of all RLV users >somehow<, that watches and respects the hardcore RLV experience, the casual one and
 the kink-averse vanilla one and can decide on the right balance because not everyone will always get what they want while respecting the essence of what RLV is.
If you (or anyone else for that matter) want to reach out with specific concerns, you have always been free to do so and it's important for me to know.

Angelina Sinclair

Kristy Aurelia Exactly, each viewer has its own code and RLV is made specifically to work with LL's original viewer. So it should be the easiest and fastest to adopt into the main viewer. 
Are you sure Kitty is working with LL to adopt this? Why is this set to planned and not In Progress? 
Also what your saying works better the other way around. If RLV code is added to the viewer than RLVa can remove all the duplicate code and bloat and stick to all its new features and commands that RLV doesn't have. That should in theory make it even easier to adopt RLVa into third party viewers.

Angelina Sinclair

Kitty Barnett It is not about preference here. It is what is better for the LL viewer and SL as a whole. In that link you provided Marine herself points out some keys to the success of RLV: Trust and Consistency.
RLVa is not consistent with RLV as new things was added. Meanwhile the commands of @buy and @pay are treading the lines of breaking Trust. To further complicate matters, RLVa does not have blacklisting while RLV does.
So to me, it be better if LL adds the original RLV spec first as linked above and then later adds new things from RLVa.

Kitty Barnett

Angelina Sinclair
> So to me, it be better if LL adds the original RLV spec first as linked above and then later adds new things from RLVa.
You realize that's not how contributions work? I will be doing all the work of adding RLVa in, cleaning the code up, refactoring, fixing bugs and adding in new commands that are relevant to the piece that's being contributed and then writing up the technical documentation for LL's use, documenting the spec in a consistent and transparent way for everyone in SL and making test content with test plans so LL's QA can do regression testing. And hopefully there's some help from other residents along the way but that's probably just wishful thinking.
LL will then review the code submissions (plural since it's just too huge to take in one go) and suggest changes based on technical merit or concerns.
> Meanwhile the commands of @buy and @pay are treading the lines of breaking Trust.
I'm not sure what @buy and @pay have to do with trust? @interact blocks you from shopping as well, at the expense of being able to do anything else in Second Life. I've always been more in favour of providing building blocks rather than having restrictions that have everything bundled together in a single take-it-or-leave it experience that may not work for someone trying to make a different scripted object than a restriction was intended for.
> To further complicate matters, RLVa does not have blacklisting while RLV does.
Because the content creators I know have spoken out against wanting to deal with their content being arbitrarily broken again and again and again over the years and I'm sure it's come up a few times but end-user wise virtually no one has ever yelled at me for not having that so I'm going to assume more people don't want it than do.
Even at the time when that was a hot topic (a bunch of content creators, me and Marine all met together about it in-world even) there wasn't a great solution proposed that would make it user-friendly. Would you honestly know what to even put in to prevent IM-blocking? I tried grouping behaviour into categories but you either end up with so many it's useless or so few that it's too broad.

Angelina Sinclair

Kitty Barnett I was only made aware 2 hours ago about the github contributions. The post here gave the impression LL themselves would be implementing RLV into the main viewer. If you are doing it then that simplifies things already but also makes much of this discussion about choosing one or the other rather pointless.
>I'm not sure what @buy and @pay have to do with trust? @interact blocks you from shopping as well
@pay blocks you from paying other avatars. This can be a problem if you have to pay rent. While @interact does something similar, it does it in a roundabout way vs what @buy and @pay does. You can carve out an exception in @interact for money stuff but not in those two commands.
>Because the content creators I know have spoken out against wanting to deal with their content being arbitrarily broken
As a long time user of RLV products from a variety of brands, I still want the option to blacklist current and future commands. Majority of these products do not update themselves on a regular basis and hoping a creator would provide choices is a pipe dream. There is already blacklist handling commands in the RLV API page link above so the code exists. So all you would need is a more fleshout window warning the user of possibly breaking content if they blacklist commands.
>Would you honestly know what to even put in to prevent IM-blocking?
Are you asking if I know how to use the blacklist feature of RLV or something else? Cause I do know how to use it.

Kitty Barnett

Angelina Sinclair
> @pay blocks you from paying other avatars. This can be a problem if you have to pay rent. While @interact does something similar, it does it in a roundabout way vs what @buy and @pay does. You can carve out an exception in @interact for money stuff but not in those two commands.
I'll need to have a look but @pay should take both avatar and object exceptions, if it doesn't that's a bug 🙈.
> Are you asking if I know how to use the blacklist feature of RLV or something else? Cause I do know how to use it.
I was asking whether you could confidently list every RLV command to blacklist to make sure your ability to IM wasn't impacted in any way, without just going through the behaviour list and how would you be sure you didn't randomly miss one? Can the average user?
Blocking to me only really makes sense if you can do it in a user-friendly way and it would certainly introduce inconsistency 😉.
Generally it also works a lot better to have problem statements, not proposed solutions. "I want a blacklist" doesn't really tell me what problem people are looking to have solved, maybe there's an alternative solution that's less disruptive? And I'm not sure this is the place for that discussion either.

Angelina Sinclair

Kitty Barnett >I was asking whether you could confidently list every RLV command to blacklist to make sure your ability to IM wasn't impacted in any way
It is not necessary to memorized every command. There is the RLV API page you can use. What makes this harder is RLVa's documentation is scattered about. So it be nice to have that all in one page.
>Blocking to me only really makes sense if you can do it in a user-friendly way and it would certainly introduce inconsistency
I mean RLVa has been introducing inconsistency already, what's a little more hmm?
>I want a blacklist" doesn't really tell me what problem people are looking to have solved
The intent of a blacklist is block specific problematic commands from affecting the user. Say you own a shop and need IMs for customers. You can list @sendIM in the black list and not have to worry about having your business affected.

Zalificent Corvinus

Angelina Sinclair
So, basically, you are saying that LL should NOT adopt the system used by the largest number of users, that's in the most popular TPV, and is the most recently updated.
Instead they should use the LEAST popular system, used in the fewest number of least popular TPV's, because you seem to have no clue what you are talking about.
You bring up insane scenarios like "a store owner might need to black list IM restrictions because their business depends on IM's", but that makes NO sense, any store owner who likes to play with RLVa restrictions, should and probably would create an un-restricted alt to run the business.
I know one business woman in SL who has an alt just to run her land baron business, so her main can enjoy RLVa.
Let's be real here, LL are too lazy to do this themselves, they are letting Kitty and Coffee handle the load for them, so since RLVa is the most popular and wide spread of the two standards, and all the work is being done by RLVa people, it's going to be RLVa.
The only thing that makes even less sense than your desires is the suggestion to do it all in LUA, the worst scripting system ever devised by the hand of geeks.

Tonya Souther

This is long, long overdue. I'm thrilled to see it be added to the Linden viewer.

For what it's worth, I prefer RLVa to Marine's implementation, both because Kitty thinks through the effects of the various parts of the specification, and because, not to put too fine a point on it, Kitty's actual code is simply far superior. Marine has treated the spec like her personal fiefdom, and that has long needed to change; it belongs to the community, not one particular gear vendor. With an official LL implementation, that will finally be the case.

Jessica Hultcrantz

I'd prefer Marines original RLV and not RLVa which is a fork and partly incompatible.

dantia Gothly

While I recognize the widespread use of RLV and the demand for feature parity, I believe that many of its functions and capabilities would be better served through proper implementation within LSL, with dedicated viewer and server support. This approach would ensure a more robust, reliable, and standardized integration, benefiting both developers and users across all viewers. Most of the functions RLVa offers shows where LSL is lacking in features.

Clem Marques

RLV is also used by some as a way to improve accessibility. This is great news.

Nyx Onyx

RLV(a) is great, but for some of the stuff it's used for, it would be great if we could have similar features in the viewer without having to use it. At the top of my head is especially attachment locking, such as being able to lock an item on myself that I wish to keep between outfit changes, instead of having to use RLVa for that purpose. I'd also like to be able to use text commands for a bunch of stuff, which in turn could be hooked up to keyboard shortcuts using gestures. Firestorm has a bunch of these, but I'd like to see a more flexible implementation, similar to how it works with "macro" recording in MS Office or similar in Photoshop for example. I can see how viewer-side Luau might open doors to such implementations, I'm just putting the idea out there now already.... Today I use chat commands with RLVa to teleport to bookmarked places for example (though could do that in Firestorm without RLVa, with the mapto chat command).

Kristy Aurelia

Just for the record, the SL Wiki page is for RLV documentation, RLVa has some additions and improvements and a few changes.

Extrude Ragu

Kristy Aurelia The documentation for RLV/RLVa is all over the place. I hope one day it is rationalized

WolfGang Senizen

Personally I would prefer if rlv could be done as a lua plugin on the lua project viewer.
This would be a perfect use case for the kind of thing clientside scripting would want to be able to do.
So implementing hooks, calls and/or an event system into the main viewer, to expose to lua, rather than just rlv in the c++ code.

Madi Melodious

Yay!!!

Signal Linden

marked this post as

planned

→