RLV: Detach and Wireframe?

[Bloodsong Termagant]

i'm using @detach=no on a hud i want to remain on me during avatar/outfit changes.

 

which is all fine, but today i got a strange message from the rlv api, stating i could not go into wireframe mode due to rlv restrictions.  i can't find anything about wireframe mode on the RLV API page, so i'm wondering if that is part of  the command (it's pretty draconian, really, you can't edit the locked object at all (which is desired, of course)), or if i have some setting turned on that i don't want on or what?

[Wulfie Reanimator]

Probably this, under "Viewer Control": http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI

Allow/prevent changing some debug settings : @setdebug=<y/n>
Force change a debug setting : @setdebug_<setting>:<value>=force (*)

[KT Kingsley]

I also see that behaviour with HUDs and @detach=n, though not with non-HUD attachments. One way around it is to use "(nostrip)" as part of the object's name and not use the @detach=n command.

I understand that using "(nostrip)" in the name of a folder will protect its contents, though I've not tested the details of this. (For example, I wonder if just making a random RLV folder, calling it "(nostrip)" and throwing links to stuff into it will work.)

ETA: No, it looks like an item has to be attached using a command that directly references a (nostrip) folder (or, presumably, though I can't be arsed to check, a folder containing a "(nostrip)" sub-folder) for this to work. 

Edited March 7, 2020 by KT Kingsley

[Coffee Pancake]

Use case - RLV Blindfold. Show wireframe would permit the user to bypass. It's a hang up of RLV's initial intention being purely adult related activities.

Suggest you fire up Catznip, press the feedback button (up by L$ value) and send a feature request for a command to lock a hud without interfering with wireframe. Give some use cases and explain exactly how you would like it to work, pick the command youd like, and special behavior .. skys the limit.

(Catznip is the viewer in which RLVa is developed, and goes from there to Firestorm etc. The feedback button in Catznip posts directly on our JIRA and will be seen and read by kitty .. who codes RLVa. If your idea is accepted, it will likely be in next Catznip release and the Firestorm release after that. Exactly when depends a lot on RL work, so its not going to be super soon ... hence telling you to do it this way, it wont get missed or forgotten about when some dev time comes up!)

 

 

 

[Bloodsong Termagant]

thanks, guys!

 

it wasn't under the setdebug command.  it really is intrinsic to the detach locking on the hud, like kt said.   but i dont see on the rlv page how to use the 'nostrip' setup.  it sounds a little complicated. ;D

 

thank you, coffee, for how to contact the RLV team!

 

[KT Kingsley]

I'm not sure where I saw the (nostrip) thing first, but if I call a HUD something like "My HUD (nostrip)" it doesn't get detached when I change outfit using RLV. That's really all there is to it.

https://wiki.catznip.com/index.php/Nostrip

ETA: I guess this feature might be exclusive to RLVa, which is what you get in RLV viewers other than the actual RLV viewer?

Edited March 8, 2020 by KT Kingsley

[Kyrah Abattoir]

On 3/7/2020 at 8:57 AM, CoffeeDujour said:

Use case - RLV Blindfold. Show wireframe would permit the user to bypass. It's a hang up of RLV's initial intention being purely adult related activities.

Suggest you fire up Catznip, press the feedback button (up by L$ value) and send a feature request for a command to lock a hud without interfering with wireframe. Give some use cases and explain exactly how you would like it to work, pick the command youd like, and special behavior .. skys the limit.

(Catznip is the viewer in which RLVa is developed, and goes from there to Firestorm etc. The feedback button in Catznip posts directly on our JIRA and will be seen and read by kitty .. who codes RLVa. If your idea is accepted, it will likely be in next Catznip release and the Firestorm release after that. Exactly when depends a lot on RL work, so its not going to be super soon ... hence telling you to do it this way, it wont get missed or forgotten about when some dev time comes up!)

 

 

 

Alternatively i'd recommend to send a note about the issue to Marine Kelley too since she is the official RLV creator and maintainer out there.

[Coffee Pancake]

7 hours ago, Kyrah Abattoir said:

Alternatively i'd recommend to send a note about the issue to Marine Kelley too since she is the official RLV creator and maintainer out there.

Marine's RLV tends to have a much tighter adult focus both in terms of raw feature intent and implementation. Additions to her specification are not automatically added to RLVa (and vice versa, significantly more commands only exist in RLVa).

RLVa is the implementation that's most widely deployed in other TPVs including Firestorm which does impact the development process. Whatever we do has to  function in way that does not create support or operational issues for non RLVa users. We also have to maintain expected behavior across a broad range of product vendors.

If you're using Marine's viewer, RLV (and her specifically targeted products) are kind of the point.

As a rule we will always try to keep RLVa in step with RLV, although there are a couple of notable exceptions (The blacklist is a nope, vision spheres are in alpha (and significantly improved / not a hack) but we're dependent on for EEP before finalizing).

 

 

[Kyrah Abattoir]

Still wouldn't hurt to send her the information too.

[Anna Salyx]

On 3/9/2020 at 4:30 PM, CoffeeDujour said:

As a rule we will always try to keep RLVa in step with RLV, although there are a couple of notable exceptions (The blacklist is a nope, vision spheres are in alpha (and significantly improved / not a hack) but we're dependent on for EEP before finalizing).

 

 

Not to derail too much here, but I've always wondered by blacklisting RLVa commands is a nope.  there are a couple I'd love to blacklist out, mainly the "permissive" command along with the "secure" forms of some comm restrictions.  is there a simple explanation that can be shared maybe?  Thanks.

Edited March 15, 2020 by Anna Salyx

[Coffee Pancake]

Just now, Anna Salyx said:

Not to derail too much here, but I've always wondered by blacklisting RLVa commands is a nope.  there are a couple I'd love to blacklist out, mainly the "permissive" command the "secure" forms of some comm restrictions.  is there a simple explanation that can be shared maybe?  Thanks.

Off the top of my head.... 

RLVa is intended as an enabler, not as a substitute for actual communication. If you don't want or like certain RLVa commands enacted upon you, raising that provides an opportunity for discussion, bargaining and compromise (all of which are more fun for everyone in an adult context).

Anyone who develops with the black list in mind will find their projects exploding in size, as they're forced to implement checks to see if every RLVa command issued gets successfully applied. This leads to toys trying to provide feedback to the operator that will invariably be framed as 'cheating' (which is significantly less fun).

All existing RLVa toys are developed with the understanding that the entire system is either on or off. Weirdness & breakage can ensue when an avatar manages to do something assumed impossible.

 

That all said, we have been discussing (and seeking feedback on) providing RLVa with a short well defined sequence of 'modes'. Each mode includes a subset of RLVa commands. Modes could be framed with clear titles such as Vanilla (all the utility non kink stuff), Locking only, Basic (excluding IM and social blocks), Hardcore (the rest) and All/Extreme (add secure locks etc). You would set your mode in viewer preferences and upon your viewer being asked to add a command from an elevated mode, you are given the opportunity to consent and increase your level of participation .. perhaps on an object by object basis. This would enable users to be informed, provide an easy way for developers to check a users mode and tailor their experience to match (without needing to manage every single command individually).

Time has been the major block, followed by working out exactly how to gracefully handle everything developed prior to such a system being implemented and working out how actual use and intended use will differ.

Whatever we end up doing it has to be clear and concise from a user perspective (you should not need to know or care about the technical specifics of various commands). Clear to scripters,  and functional with all the legacy stuff.

The goal has always been to develop RLVa from the perspective of a fun and useful tool box, we totally appreciate that 'all or nothing' is less than ideal. This idea has been kicked back and forth during development for a long time now and while it addresses a couple of specific issues, it's problematic with how RLV tends to be used (hush now, click click click click) and doesn't address the most common non command specific problems people have (like lock and leave).

At the end of the day, a good RLVa experience has to involve communication, and we're not wanting to do anything that will detract from that, or easily reframe a users personal choices in a negative way.

[KT Kingsley]

2 hours ago, CoffeeDujour said:

[...]

All existing RLVa toys are developed with the understanding that the entire system is either on or off.

[...]

I've had the vague impression that the RLV relay protocol specifies the return of either the string "ok" for when an RLV command has been accepted and implemented, or "ko" (knocked out?) when it hasn't. And there's also the base assumption – for any IT-related situation – that if you don't get a response, it hasn't happened.

Edited March 15, 2020 by KT Kingsley

[KT Kingsley]

3 hours ago, Anna Salyx said:

Not to derail too much here, but I've always wondered by blacklisting RLVa commands is a nope.  there are a couple I'd love to blacklist out, mainly the "permissive" command along with the "secure" forms of some comm restrictions.  is there a simple explanation that can be shared maybe?  Thanks.

I guess because there's "recreational" and "functional" or "utilitarian" RLV, and "lifestyle" RLV usage.

Nearly all my RLV usage is of the "utilitarian" type, but I do usually keep an open RLV relay going in the vain hope that someone, somewhere, will, one day, try something unexpected and entertaining on me.

But... there's plenty of RLV restrictions that seem to me would only appeal to the type of RLV user who might only be described, politely, as an arsehole.

So... my self-written relay script includes white/grey/black lists of RLV commands (because relogging in a non-RLV viewer, to get out of a mess... ok, so the mess is usually caused by me mis-scripting something... is a pain) – (and based on a "sounds like", wildcard – "*" – matching function, which I'm smug enough to be rather pleased with, but nowhere near confident enough about to post publicly and suffer the consequential ripping to shreds).

[Coffee Pancake]

There is a distinction to be drawn between worn objects that act directly on an avatar and relays, although neither are immune from aggressive "anti cheat" coding practices ending in a mess that the user has no choice but to bail out on.

[KT Kingsley]

On 3/15/2020 at 8:50 PM, CoffeeDujour said:

There is a distinction to be drawn between worn objects that act directly on an avatar and relays, although neither are immune from aggressive "anti cheat" coding practices ending in a mess that the user has no choice but to bail out on.

So far it's only been bugs my own RLV scripts that have left me in a mess with no choice but to bail out.

[Coffee Pancake]

Learn't that one the hard way sitting in a club, working on a script in a hud attachment ^^

[Paul Hexem]

Gonna bump this one back up to see if anyone's ever found a fix for this.

Losing wireframe disables a fix to SL's unfixed mesh rendering bug. It's pretty vital to have.

[Quistess Alpha]

49 minutes ago, Paul Hexem said:

a fix for this

Assuming 'this' is to have a HUD 'locked on' but not disable wireframe mode. . . no. Just for a list of things that do lock on but also disable wireframe mode availability:

list cmd =
[   "@clear","@clear,detach=n","@clear,detachthis=n","@clear,@detachthis:testing=n","@clear,sharedunwear=n"
];
list desc =
[   "unlocked","locked","self-folder locked","direct folder locked","shared folder locked"
];
integer ind;
default
{   touch_start(integer total_number)
    {	ind = (++ind)%5;
        llOwnerSay(llList2String(cmd,ind));
        llOwnerSay(llList2String(desc,ind));
    }
}