rlva_troubleshooting - clarify group tag and active group, emphasizing a few words

Typical RLV issues that might not be immediately obvious:

• Hover height changes on its own:
  • OpenCollar does this for its posing function. The user can consult the OpenCollar manual to clear all pose heights.

• Reset to default male / female does not work:
  • RLV disables this function entirely.

• Release Controls is grayed out:
  • RLV disables this function when at least one attachment is locked.

• Hide HUDs menu is grayed out:
  • RLV disables this function when at least one attachment is locked.

• HUD zoom stops after a small amount:
  • RLV limits HUD zoom when at least one attachment is locked.

• Wireframe mode is grayed out:
  • RLV disables this function when at least one attachment is locked.

• Blacklisting a user's own attachments does not work:
  • RLV disables this function entirely.

• The user sees “xxx executes @xxx=n” messages in chat:
  • RLVa / Debug / Show Debug Messages is enabled.

• Blurry screen, even after disabling RLV:
  • Debug setting: RenderResolutionDivisor ⇒ DEFAULT

Very often, a user's issue is mistaken for an RLV problem, but most of the time, RLV is not involved. The user can open the RLVa / Restrictions menu function to look at the currently active RLV restrictions and see which object is responsible for them. Most of the time, the names of these restrictions are very clear, but for a full list you can check the RLV API on the Second Life wiki.

Querying a user's RLV status:

RLV supports a few remote commands that can be sent in an instant message to see the status of their RLV. Here are the most important ones for identifying an RLV issue:

• @version - Sends back the user's RLV version immediately.
• @list - Sends the contents of the RLVa / Restrictions list after getting permission from the user.

Following is a list of things that often are attributed to RLV restrictions, but are in fact not RLV issues at all. Please keep in mind that the viewer has an enormous amount of functions and RLV is very complex, so we can not provide an exhaustive list of all possible things that might or might not be RLV related:

• A user is stuck in an animation, a user's animations don't play when sitting on a seat:
  • RLV by itself does not affect animations at all.
  • Animations that don't play can be AO issues, or lately certain “posing” HUDs (including HUDs for mesh heads/bodies).
  • There are of course attachments (e.g., collars, capture HUDs) that use RLV and have scripted functions to animate an avatar. These will still be able to play animations when RLV is disabled. So the best approach here is to check where the animation is coming from (e.g., World ⇒ Animation Explorer), and stop the animation from within this attachment. See What if I can't control my RLV attachment.
  • See Movement Issues for other causes.

• The FS AO gets enabled or disabled without user interaction:
  • RLV does not know about the Firestorm Client AO.
  • There are attachments like collars, or in-world objects, like furniture, that use either the OpenCollar or Lockmeister commands to switch the AO on or off; see here for details. This function is part of the LSL Client bridge and can be enabled or disabled in Preferences ⇒ Firestorm ⇒ Avatar ⇒ LSL-Client Bridge external protocols integration.

• A user can't walk, does not fall, snaps back to a specific place, or moves around by themselves (without teleporting):
  • RLV will not stop a user from walking or cause them to walk or jump around.
  • A regular LSL script can move the avatar around, take and disable keyboard controls, and keep them locked in a specific place by itself.
  • The most likely cause is movelock, flight enhancer, a stuck LSL Client Bridge (try recreating the bridge), a leash from a collar (unlock the collar, unlock the leash, find a collar that was dropped on the ground by mistake) or lately certain mesh head or body HUDs. Start taking off attachments and see which one is the cause. If the culprit in fact is an RLV attachment, seeWhat if I can't control my RLV attachment.

• A user can't take snapshots:
  • Not an RLV issue at all. Often a problem with excessive resolutions, or an antivirus blocking snapshot saving.

• A user is stuck in mouselook:
  • RLV can not lock a user's mouselook.
  • A regular LSL script can put a user in mouselook on attach or on sit, but not after that.
  • RLVcan limit the user's camera distance to pull it into the avatar head, making it look similar to mouselook, but without the actual “looking around” part. This would show in the restrictions list as an @camdist* or @setcam_* restriction, including the actual distance.
  • RLVcan change the user's FOV (ctrl8, 9, 0), and block changing it. The block will also show in the restrictions list.

• An attachment can not be detached:
  • RLVcan lock attachments, but that will make the “Detach” menu item gray out. If the menu is not grayed out, it's not RLV locked. More help here.

• An attachment, piece of clothing, or system body layer can not be worn/added:
  • RLVcan block wearing of attachments and system layers. But that will also gray out the respective menu entry. If the entry is not grayed out, the problem is not RLV. If it is, make sure the user is not maxed out on layers or attachments first. Then check the restrictions list for things like “addoutfit” or “addattach.”

• Changes to active groups and switching tags:
  • RLVcan block the user from changing the active groups and/or tag, and can force a change to a specific group and/or tag.
  • RLV can not block the viewing of group profiles, seeing group tags only, or doing group administration work.

• Group Chat:
  • RLV can not modify or block sending group chat if the chat is already open. It will always send a message that tells the receiving group RLV is in use.
  • RLVcan stop a user from opening a group chat or IM in the first place.

• Unable to touch objects:
  • In mouselook: Usually caused by an attachment taking the mouselook click controls to circumvent no-script parcel restrictions. Detach attachments one by one to find the one that does it (Maitreya body is one of them, as are some mesh heads).
  • RLV can block touching objects, either by distance, by type or everything. It will gray out the respective “Touch” menu entries and play a “forbidden” sound effect when a right-click from too far of a distance is performed.

• Unable to see object contents:
  • RLV can not hide object contents, only stop the user from editing an object altogether.

• Anything with Media or Voice:
  • Not an RLV issue.

• Anything with buying products or spending money overall:
  • Not an RLV issue.

• Anything with clicking/selecting inventory items:
  • Not an RLV issue.
  • RLVcan restrict renaming and deleting items from inventory inside the #RLV folder.

• Anything with the viewer interface, apart from graying out or closing floaters
  • Not an RLV issue.

• Anything before the user logs in:
  • Not an RLV issue.
  • RLVcan, however, force the user to always log in at last location. This is not visible on the login screen because the viewer doesn't know yet which user will be logged in.

Some RLV functions are not applied as restrictions, so they can not be seen in the restrictions list. These include:

• Removal of attachments
• Removal of clothing or alpha layers
• Rotating the avatar
• Teleporting without user interaction (could be done by an Experience script)
• Force sitting on a seat (could be done by an Experience script)
• …

If such a command is suspected of being sent to the user, they can enable RLVa → Debug → Show Debug Messages and watch nearby chat for any @xxx=force commands being received. These will be prefixed by the object that sends them to allow identification. If such a command is not seen, and the effect is still happening, it was not done via RLV.

If the attachment does not allow the user to change things, they might need to ask the person who operated the attachment, or disable RLV entirely to detach the item.