RLVa

*waves*

I just woke up from my hibernation to wish everyone a merry Christmas and a happy new year!

(Please don’t tie up Santa when he comes down the chimney and hog him all to yourself. The rest of us want our prezzies too!)

 —

On a more serious note there’s finally light at the end of the tunnel for RLVa-1.1 (woohoo!).

Since a lot of the changes are internal only (moving code around to where it makes more sense and completely rewriting other portions) I’d rather do an “interim release” where I release a (Windows only though, sowwies) viewer in the next few days and hopefully can get some feedback (and quick bug fixes if necessary) before I do a normal release and move on to integrate it into Emerald and Imprudence (where the release cycle is at least several weeks).

 —

I’ll put up the actual change list when I actually release but in the meanwhile:

 1) “Enable Shared Wear”

This feature is aimed primarily at those who are using the “force wear” functionality of RLV but aren’t using the attachment locking functionality: when enabled it removes the requirement for shared inventory attachments to specify which attachment point they should get attached to.

If at least one attachment point is non-detachable or non-attachable then “Shared Wear” will automatically be disabled.

(Note that “Enable Shared Wear” disables the auto-renaming that normally happens when wearing an attachment that resides under #RLV)

 2) Auto-move “no modify” attachments under #RLV when worn

Example: “Wear” on a “no modify” attachment called “Collar” that attaches to “chest”
Result: the viewer will create a new folder called “.(chest)” under the current folder and move the “Collar” inventory item into it

This complements the existing auto-rename for modify attachments and makes setting up a shared folder as easy as right-clicking it and picking “Add to Outfit” (as long as “Enable (Default) Wear” is enabled).

Hopefully this makes up for the fact that “Shared Wear” is disabled as soon as at least one attachment is locked .

 3) “Unable to open [TYPE] due to RLV restrictions”

When you double-click a notecard/texture/script when @viewnote/viewtexture/viewscript restricted it can be frustrating when it doesn’t open up and it might take a minute before you realize that it’s due to a currently enforced restriction.

To complement greying out “Open” on the context menu you’ll now see an “Unable to open texture due to RLV restrictions” if you double-click a texture when @viewtexture restricted.

(Keep in mind that you also can’t open notecards or scripts inside of non-detachable attachments even if you’re not @viewxxx restricted)

 4) Hardcoded strings now live in rlva_strings.xml

This isn’t really a feature or something most people will care about but it does have some side-effects that might appeal to a few people:

• If anyone wants to help and translate the strings into one of the languages the viewer supports that would definitely be appreciated
• You could change the text that gets sent out when someone IMs while you’re @recvim blocked for instance
• The list of “anonyms” that @shownames uses is customizable (you can replace existing ones or extend the list by adding your own custom ones)

 5) “Force wear” will activate/deactivate gestures

Nothing earth-shattering but someone might find it useful.

 6) Better command handling feedback when RestrainedLifeDebug is TRUE

First of all “unset” behaviours (ie @detach=y without a preceding @detach=n) and “duplicate” behaviours (ie @detach=n followed by another @detach=n) no longer show as “failed”.

Instead you’ll see: “Object executes: @detach=y (unset), detach=n, detach=n (duplicate)”

All commands perform validation as well which clears up several personal pet-peeve bugs and hopefully makes it easier for script creators to catch errors as well.

Examples:

• Object failed: @detachme=n (invalid  param)
  -> only @detachme=force has any meaning
  -> note that if you issue @getstatus on the object it *will* still report /detachme so it doesn’t break being able to set nonsensical behaviours
• Object failed: @detachme:spine=force (invalid option)
  -> “spine” isn’t a valid option to supply to “detachme”
• Object failed: @detach:test=force (invalid option)
  -> in this specific case “invalid option” means “no such folder exists” (I might make that clearer if anyone cares about it strongly)
• Object failed: @attach:test=force (missing #RLV)
  -> command failed because the user has no shared #RLV folder
• Object failed: @foo=bar (syntax error)
  -> should be fairly obvious
• Object failed: @setenv=n (command disabled)
  -> user set RestrainedLifeNoSetEnv to TRUE
• Object failed: @showminmap=n (unknown command)
  -> helps finds typos

 7) @version and @versionum execute at regular intervals throughout the logon

The old behaviour was that all commands were retained until about the time the log-on screen disappears but it seems there are a few scripted items out there with a very short time-out (and some people who take a long time logging on) so hopefully responding to @version and @versionnum at regular intervals will fix things.

 8) UI tweaks

• “Teleport Home” is now visually disabled when @tplm=n restricted to make it more obvious that it’s blocked
• “Sit” and “Stand Up” weren’t visually disabled on the pie-menu when @sit=n/sittp=n/fartouch=n and @unsit=n restricted
• The cursor no longer changes to indicate a “special action” if it’s something that’s blocked anyway (ie if you hover the mouse over a touchable object that’s >1.5m away under @fartouch=n the mouse cursor won’t change away from the default pointer)

 9) Showing a custom notification when X restricted

This is actually a scaled down version of something else I wanted to put in that didn’t quite work out in the end but since it’s only a handful of lines I thought I might add it in anyway and see if it’s of any use to anyone (so please do let me know if you’re using it or it might go *poof* at some point).

Practical example: if you want to know when you’re @recvim restricted you could add a notification with the text “Unable to still receive IMs” and “Able to receive IMs again” and you’d see the first notification on the *first* (but not subsequent) @recvim=n restriction and the second notification on the very *last* @recvim=y restriction.

(You could accomplish more or less the same thing with @notify and @getstatus I guess)

Take a peek at rlva_strings.xml if you want to play with it (there’s a commented out example for @defaultwear there)

 —

There are some additional “experimental” features as well that I didn’t mention here because depending on feedback they may or may not make the actual release so I’ll highlight those when I put up the RC in the next few days.