User:Kitty Barnett/RLV

I’ve been somewhat bored with LSL projects lately so tinkering with the RLV viewer seemed like a welcome diversion :p.

Unfortunately there doesn’t really seem to be a way to get external patches into RLV, and since there is no public forum to discuss what would be a common request/change this will be limited to things I personally care (or am curious) about.

(Unless otherwise noted all patches were made against SL-1.22.11/RLV-1.16.1)

Note: please do check with me if you’ll be using a particular patch since maintaining them individually “per change” like I’m doing here is very time-consuming so beyond the initial posting I likely won’t be keeping them up to date as-is so I might have added/fixed something that isn’t reflected here.

If you have a suggestion, feel free to add it to the talk page or just give me a poke in-world :).

@fartouch related crash

Repro:

Rez a prim
Issue @fartouch=n to yourself
Make sure you’re >1.5m away from the prim, hold down Ctrl and left click (= crash)

Patch: [1]

nostrip

Some attachments or clothing layers are an inherent part of someone’s avie (a tattoo, a tail, ears, an entire prim avie, etc).

Having those “essential” items stripped off can be rather annoying (especially when @addoutfit=n or @showinv=n restricted) and dropping a script in everything isn’t always possible (no mod) or practical (for attachments the wearer has to remember to lock them, @detach=n will prohibit regular “Wear”’ing or an unlock is needed before anything else can be worn on the same layer/attachment point, …).

In short: the idea isn’t to have those layers/attachments locked on, but simply exempt from @remoutfit=force and @detach=force. “nostrip” is used in the same way you would direct RLV to attach something to say “pelvis”: by adding it to the name of the item or its parent folder.

Examples:

Paw Tattoo (nostrip) <- @remoutfit:undershirt=force won’t remove the layer
Folder structure:

Prim Nails (nostrip) 
|- French Tip L  <- @detach:left hand=force or @detach=force won’t detach the nail(s)
|- French Tip R

Patch (fixed version, the first one didn’t account for @detach=force to force off all attachments): [2]

AvatarSex

Contrary to the RLV documentation, this doesn’t come from your sign-up details but is derived from the shape you’re wearing. Additionally the regular viewer doesn't keep the debug setting in sync across shape changes or even sets it until the first time someone goes into appearance (so male avies are stuck with AvatarSex == female until the first time they go into appearance).

I’m also unsure why someone would want to change it as well since AvatarSex is implicitly tied to shape, so changing it should change the shape from female->male and vice versa? *confuzzled*

The patch removes the ability to change the setting and ties retrieving it directly to the sex of the currently worn shape so it’ll always return the correct value.

Patch: [3]

@fartouch glitch

Repro:

Issue @fartouch=n to yourself
Make sure you’re >1.5m away from the prim
Open the Build floater (Edit tool – Ctrl-3), pick “Select Texture” and click on a face of the prim
Since the prim is now selected you can now “Touch” it through the pie menu (along with anything else you can do from the build menu)

Patch: [4]

@shownametags aka “shownames-lite”

Intended for things like blindfolds or any situation where you’d want to hide people’s names, but don’t want to deal with the extensive name censoring of @shownames.

Most, but not all, @shownames restrictions that deal with hiding the names (but not censoring them) are enforced. Deciding which one makes the cut and which one doesn't is a subjective choice so do consult the patch to find out.

Also, since @shownames > @shownametags I subtly modified the meaning of the "RRInterface::mContainsXXX" variables: instead of being a 1-on-1 match of what's in sSpecialObjectBehaviours it's simply a check of what the viewer should currently be restricting. As a practical example:

@shownames=y,shownametags=n yields 'mContainsShownames == FALSE' and 'mContainsShownametags == TRUE' as expected
@shownames=n on the other hand yields 'mContainsShownames == TRUE' *and* 'mContainsShownametags == TRUE'.

Doing this cuts down on the amount of code that needs changing, it also prevents checking for "mContainsShownames" but not "mContainsShownametags" (or vice-versa) which can create subtle bugs. Lastly, it also makes it easier to apply the patches when Marine updates RLV (see below: @touch=n benefits from any future changes to @rez=n or @fartouch=n without the need to change the new code).

Patch: [5]

Interaction blocking / @touch=n

The Real Restraint (and other brands) cuffs have the ability to “block interaction” but currently require that a HUD is used to prevent interaction.

Changes:

The cursor no longer changes for objects that are outside fartouch range which gives a valuable visual clue on just what is clickable within range (when @fartouch=n)
@touch=n is – partially – implemented as a special case of @fartouch=n with a touch distance of 0.0m (all references to the hardcoded 1.5m are replaced with an – inlined – call to RRInterface::getFartouchDist())
@touch=n includes the @rez=n restriction
Block all hover tips (when @touch=n)
Block pie menu (when @touch=n)
Cosmetic changes (from memory: changed a “true” to “TRUE” somewhere, cleaned up references to RRInterface::contains() for “cached restrictions” as I came across them, …)

Differences between @touch=n and HUD based interaction blocking:

HUDs are still accessible and useable (by design): a HUD based AO needs to be able to be turned off, a HUD based relay needs to be able to be configured, etc…
The camera is unrestricted (by design): it’s already possible to Ctrl-Alt-Shift cam around with a HUD-based design so this doesn’t add anything that isn’t already possible (if the camera does need to be limited it might be more useful to look into a specific restriction for that which could be used to prevent camming out of an enclosed space like a room or cage for example)

Patch: [6]

(This was a quick proof-of-concept patch so I haven't tested it extensively yet. If I come across a way to evade it I’ll update the patch accordingly)

Forced mouselook / @thirdview=n

(@thirdview seems to be the unofficially used command so I’m just going with what’s there)

As with interaction blocking, the viewer restriction is based on how restraints currently work: it’s entirely possible to go out of mouselook (there are some basic things that just can’t be done in mouselook – ie standing up when sitting), but the screen will blank (@touch=n will also be set to prevent any in-world interaction).

In addition, going out of mouselook starts a 30 second grace period after which the viewer will return to mouselook (ideally it would pop up a notification but that would require changing the xml in the skins folder and also having a translation for every language SL support).

Patch: still needs minor cleaning up / testing, will be posted tomorrow