With my connectivity issues, the failed hard disk and the fact that the end of the month is always the most stressful time at work it seemed like I wouldn’t have much time to actually do anything for another week or so, so I decided to do a “preview release” of RLVa-1.2.0 for those who want to help test and/or want a peek. All one or two of you reading this anyway .

Most of everything should work, notable exceptions are @showloc=n and @shownames=n though… they’ll work in some places but not across the board yet (they’re exceptionally tedious to implement and 2.0 made it a whole lot more complicated and added a great many more places to hide names and/or location from).

For the moment my “still to do” list is along the lines of:

• finish everything up (ie @shownames=n, @showloc=n and probably some random things I’ve forgotten about)
• re-test everything from scratch again
• find some way to make the “composites” feature play nice with inventory links (they’re non-functional at the moment, sowwies)
• when Marine releases re-verify that my idea of what should be blocked by which restriction matches up since we’ve very likely gotten out of sync there

So still quite a bit of work left .

—

I’ll blog about this more (and it’s subject to change until everything’s all done), but some 2.0 vs RLV API clashes to watch out for that I can think of straight away:

• if you use inventory links in your #RLV shared folder then @getpath (and as a result all of the @*this commands) will not return a path (on the plus side I’m not sure if any/many scripts actually use that command)
• if you use inventory links in your #RLV shared folder then @getinvworn will return less useful information (ie since every link is worn if the link target is worn you’ll see a lot of folders that are partially worn which might confuse some existing scripts)
• @detach=n from an attachment on (as an example) “spine” is no longer a synonym for @remattach:spine=n due to the upcoming “multiple attachments per attachment point”. The former “locks” an attachment *object* while the latter “locks” an attachment *point* (you can execute both commands and then look at the RLVa / Debug / Locks… floater to see the difference)
• the tattoo and alpha layer are part of what gets stripped due to @remoutfit=n which may lead to undesirable results (ie an alpha wearable to work in tandem with a prim corset) so use “nostrip” for those if need be

—

Changelog (now even more boring than usual :p): release_notes_RLVa-1.2.txt

I’m keeping the “Catznip viewer” and this blog separated, if only because this one is supposed to be about the “RLVa patch” and not a viewer so (and it keeps this blog free of TPV policy legalese and related hoops)…

While it would certainly help me to have other people test it before it becomes part of Emerald or any other viewer I’m not trying to convince anyone to use it. You either feel comfortable with it, or you don’t .

And now the actual link: Catznip blog

—

(Sorry if this blog seems rushed and inconsistent but it’s 2:20am here now and this little Kitty really hears her bed calling! )

I’ll be blogging about SL-2.0 / RLVa-1.2.0 in a few days but I just wanted to list the changelog for RLVa-1.1.1:

• fixed : the first teleport after log-on can’t be cancelled
      -> fixed in Emerald but was never fixed in the main branch
      -> backported from RLVa-1.2.0a
• fixed : @redirchat:<channel>=add filters emotes (thankies Toy and Chloe)
      -> see release notes for RLVa-1.0.0f: decoupled @recvchat=n’s emote filtering from @emote=add due to @recvemote=n
      -> broken in RLVa-1.1.0h due to: @redirchat and @rediremote now use exceptions to store the redirection channels
      -> backported from RLVa-1.2.0a
• fixed : @tpto:<option>=force teleports should not be abortable (thankies Satomi)
      -> backported from RLVa-1.2.0a
• fixed : chat animation isn’t inhibited for emotes when @rediremote restricted
      -> backported from RLVa-1.2.0b
• fixed : @sit=n doesn’t block sitting on land
      -> backported from RLVa-1.2.0c
• fixed : “A person” anonym in rlva_strings.xml has a stray quote (thankies Satomi and Tammy)
      -> backported from RLVa-1.2.0c
• fixed : @recvim=n sends a busy message when the sender is muted
      -> backported from RLVa-1.2.0e
• fixed : @detach=n,remattach=n,remattach=y results in a detachable attachment
      -> attachment point locks were using a map instead of a multimap… eep!
      -> created a complex bug where only the first lock for any specific attachment point is active
• fixed : @acceptpermission doesn’t auto-grant PERMISSION_TAKE_CONTROLS to objects with a different owner (thankies Dahlia)

Emerald specific:

• fixed : “Edit Attachment” doesn’t respect @edit=n (forgot who told me about this one, sowwies )

(It looks like some silly Kitty forgot to actually update the version number in Emerald so it’s still saying 1.1.0 while it’s actually 1.1.1… this is what happens when you commit code at 4am )

A few people keep nudging me to talk about the elusive “composite folders” that are part of RLVa-1.1.0… I’ve actually tried to write this blog post at least half a dozen times already but it always get so terribly convoluted and complicated by the third paragraph that I doubt it would still make sense to many people, so… brace yourself .

—

If you’re wearing a pair of shoes in SL then they’ll likely consist of at least a shoe base and left/right foot attachments; or possibly left/right lower leg attachments as well; or even left/right upper leg attachments (thigh high boots for instance).

Similarly a dress is usually at least a shirt (and/or jacket), plus pants, plus a prim skirt. Or some extra frills on chest, and sleeves on left/right upper arm, etc.

Regardless of what individual items actually compose it we just refer to it as “shoes” (or “dress”) and that’s more or less the idea behind “composite folders”: grouping multiple inventory items together and treating them as “belong together”.

—

Practical example: a playboy bunny outfit

If you ignore the unusual “.[something]” naming scheme for a moment you’ll notice that I’ve divided the outfit into different parts:

• the leotard: comes on shirt and pants layer, plus the bunnie tail (which goes on pelvis)
• the tights: come on underpants and socks layer
• the shoes: shoes layer plus left/right foot attachments
• my prim nails: gloves layer plus left/right hand attachments

So what’s the big fuss?

Imagine that someone’s feeling playful and suddenly *yoinks* my bunny tail off (@remattach:pelvis=force): normally that would remove only the tail but instead the viewer will actually strip off the tail, the shirt layer and the pants layer because I told it to treat all three items as one whole (by grouping them under a “composite folder”) so if one of them gets removed then all the others should be removed as well.

(Including the tail as part of the leotard was a quirk on my part: if the tail was located where the ears and collar are then it wouldn’t belong to a “composite folder” and wouldn’t result in anything else being taken off)

Similarly if something now executes @remoutfit:shoes=force then that will strip the shoe base *and* the left foot attachment *and* the right foot attachment.

—

Q: what happens when another folder is force-attached and it replaces part – but not all – of a composite?

For instance imagine that the new folder contains stockings instead of tights: normally that would mean that you have to Take Off > Underpants on your own.

However since the tights are marked as a composite as soon as one piece of it is replaced the viewer will take off the rest as well so in this case replacing the socks layer means that the underpants layer will automatically come off as well.

As an another example: if the new folder contains actual gloves on the glove layer then that would cause the left/right hand prim nails to get detached since the gloves replaced their tinting layer.

—

Q: what happens if part of a composite is locked and another part is force-stripped?
A: nothing, the strip command fails

When a pair of shoes is marked as a “composite” for instance then a @remoutfit:shoes=n to lock the shoe base will automatically extend to the left/right foot attachment as well.

(Note that it doesn’t prevent *you* from still right-clicking and detaching them, all the “composite logic” applies to *scripts* only)

—

Q: what happens if a composite is force attached and parts of it specify layers or attachments that are currently locked?

That might not make much sense so consider the previous example of having the shoe base locked as part of @remoutfit=n but not having the left/right foot attachment locked.

Now imagine that someone is trying to force-attach a pair of boots on you: the previous paragraph tells you that since the shoe base is locked the left/right foot attachment are considered to be “locked” as well so that leaves only the left/right lower leg attachments.

Which as you might have guessed will not attach at all because if even one item of a composite can not be attached then none of it will get attached (or in other words composites are always an “all or nothing” deal).

—

Some closing comments:

Naming - in the example I used “.[something]” for the simple reason that I always want my shared outfit folders to be attachable through a simple @attach:<path>=force (do note that regular RLV will treat this kind of composite folder as a regular hidden folder so if you switch then you want to stay away from this one).

If you prefer you can just use “[Something]” as well in which case it would take an @attachall:<path>=force to attach the entire outfit (and of course the folder would be visible to @getinv).

I also realize this isn’t the best naming scheming in the world and will likely conflict with the way some people have already set their folders up and this will likely change at some point soon (ie the next version).

Additionally keep in mind that only shared folders (any folder somewhere under #RLV) can be composite folders. Every folder anywhere else in your inventory that happens to be named “[Something]” will just be a normal, plain folder.

Bugs – I have to honest and point out that I didn’t really bother testing composites all that much after implementing them since I wanted to spend more time making sure that they didn’t break “normal” force wearing.

That said the very few people (three in all I think) who knew what they were about and have used them to some extent haven’t reported any bugs so they should be fine to play with. Just don’t do any crazy things like nesting composites inside of another composite .

Enabling - once turned on *any* folder under #RLV that’s named “[blah]” or “.[abc]” will be treated as a composite folder so please make sure you never named any folders like that or they’ll suddenly start acting peculiar .

If the above didn’t scare you off then you just flip RLVaEnableCompositeFolders from the default FALSE to TRUE under “Advanced / Debug Settings” and you’re all set (applies to RLVa-1.1.0).

—

*breathes* I actually made it all the way to the end!

Emerald just released so that means the test phase for RLVa-1.1.0 is finished as well .

—

The lists below aren’t exhaustive but highlight additions/changes/fixes that “most people” might care about (see the release notes for the full change log).

New additions:

1) Auto-create folder for “no modify” attachments under #RLV when worn

If you “Wear” (or “Attach To”) a “no modify” item somewhere under the shared #RLV folder the viewer will automatically create the appropriate “.(attachpt)” folder and move the item into it (if it doesn’t already exist).

This should hopefully make creating shared folders easier since – as long as you have “Enable Wear” – all you have to do is move the items to a folder under #RLV and then pick “Add to Outfit” and you’re done .

(If for any reason you *don’t* want items under the #RLV to be auto-renamed – or auto-moved – you can uncheck “Advanced / RLVa / Debug / Rename Shared Items on Wear”)

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

When you double-click a notecard/texture/script when @viewnote/viewtexture/viewscript restricted (or when trying to edit a script inside of a non-detachable attachment) 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.

So 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.

(Depending on the like/don’t like I’ll add similar ones for other “silently blocked” things like teleporting)

3) “Force wear” will activate/deactivate gestures

Nothing earth-shattering but some people might find this one useful.

4) Hardcoded strings now live in rlva_strings.xml

This isn’t really 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) Avatar-to-avatar “Give to #RLV”

A few people suggested this one: if they @showinv=n restrict someone they wanted the ability to “force wear” something on that person without first unlocking that person’s inventory and then asking them to move the folder they just received to their #RLV.

6) 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)

7) 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.

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

8 ) 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

9) “Composite folders”

This really deserves its own blog post. I just added it here so people can poke me to explain what it does :p.

—

Fixes:

1) @version and @versionum execute at regular intervals throughout the log-on

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.

2) @setrot:<angle>=force rotates clockwise while regular RLV rotates counter-clockwise

(This one was actually fixed “early” in Emerald and Imprudence but I’m not sure if either released since it was fixed)

3) “folded” folders should inherit “nostrip” from their parent folder(s)

(ie #RLV/Test (nostrip)/.(spine) should be “nostrip” since it folds in under “Test (nostrip)”)

—

“Enable Shared Wear” (the ability to do away with having to specify attachment point names for shared inventory folders for non-D/s use) unfortunately had to be removed due to SVC-5383 :(.

The “experimental” commands are present in the code but are *not* available unless you #define RLV_EXPERIMENTAL_CMDS (see rlvdefines.h). (I’ll update the preview viewer soon to reflect RLVa-1.1.0 and Snowglobe 1.3 RC1)

—

For people already using the patch: I moved the #include’s for rlv*.h from llagent.h to each individual *.cpp file so that might result in quite a lot of rejects. It’s not something I did very lightly but it drastically reduced the amount of time it took me to do a rebuild of the viewer.

I also don’t think there are still any viewers using SL-1.22.11? If I’m wrong please just ask for a patch and I’ll make one .

I also have a patch for Snowglobe-1.2.4 if anyone’s specifically interested in that one, but it seemed that with an imment Snowglobe-1.3 it might not be needed/desired.

If there are any problems with any of the patches please do let me know and I’ll try my best to help .

Code downloads:
RLVa-1.1.0o_20100218_SL-1.23.5-full.patch – SL-1.23.5
RLVa-1.1.0o_20100218_Snowglobe-1.3.1-full.patch – Snowglobe-1.3.1

RLVa-1.1.0o_20100218_SL-1.23.5-diff.patch – From 1.0.5e to 1.1.0o (SL-1.23.5)

Release notes:
release_notes_RLVa-1.1.0.txt

As announced I’m releasing a preview viewer but will also move on to merging RLVa-1.1.0 with Emerald and Imprudence and sorting out viewer-specific RLVa-related issues today and hopefully have that done by the end of the week.

About the preview: on the one end it would be helpful to get some early feedback about any bugs or issues relating to RLVa-1.1 (particularly things that currently work fine in RLVa-1.0.5) since there have been a lot of “under the hood” changes (see Happy holidays post). On the other hand there are a limited few “experimental commands” in RLVa-1.1.0 as well that I can’t really make a part of the normal release so the preview is a way for those people who are interested in them to actually try them out, give feedback and to refine or adjust their feature proposal.

About the name: I can’t keep the Snowglobe name for the viewer and an “RLVa viewer” is much too close to Marine’s “RLV viewer” so I just went with “Catznip” instead to avoid any confusion. Since the only purpose for the viewer is to hopefully get some early feedback on – obvious – bugs or on the experimental commands that won’t be part of the normal release it should work fine .

Condensed installation instructions (Windows only):

• download and install the Snowglobe-1.3.0 test build from LL (http://secondlife.com/developers/opensource/downloads/2009/trunk/3064/Snowglobe_1-3-0-3064_Setup.exe)
• download the preview and extract everything into the folder where you installed Snowglobe-1.3.0 (http://rlva.catznip.com/downloads/Catznip/Catznip-1.1.0.11.zip)
• double-click the Catznip-1.1.0.11.exe and change the cache folder to something specific for this viewer. Using the same cache folder for different viewers seems to cause some issues so please don’t skip this step

Notes:

• RestrainedLife setting is set to TRUE by default
• The viewer will use settings_catznip.xml by default so it won’t interfere with your regular user settings (although it does mean you’ll have to reset your preferences)
• There might be a few silly idiosyncrasies related to changing the branding on the viewer (ie during yesterday’s inventory server outage I noticed that the error stated “Couldn’t connect to Catznip” instead of “Couldn’t connect to Second Life” )

Source:

• the base build is Snowglobe-1.3.0 (=trunk) revision 3064 3065 which you can get from LL’s svn
• after you checked that out (as well as extracted the art and libs file) download http://rlva.catznip.com/downloads/Catznip/Catznip-1.1.0.11_src.zip and just extract it on top

(If someone really wants a patch file instead just let me know and I’ll put one up but I didn’t want anyone confusing this with the actual release)

(The source also hasn’t been compiled by someone using Linux or a Mac yet so there’s likekly to be some GCC-specific warnings/errors and if so please do pass those on)

Release notes (tentative): release_notes_RLVa-1.1.txt

Experimental commands:

• General outline (or just click the “Request for Comments” link at the top): http://rlva.catznip.com/blog/request-for-comments/
• @allowidle=n: http://rlva.catznip.com/blog/request-for-comments/rfc-allowidlen/
• @touchXXX=n: http://rlva.catznip.com/blog/request-for-comments/rfc-touchxxxn/
• @interact=n: http://rlva.catznip.com/blog/request-for-comments/rfc-interactn/
• @findfolders: http://rlva.catznip.com/blog/request-for-comments/rfc-findfolders/
• @getXXXnames: http://rlva.catznip.com/blog/request-for-comments/rfc-getxxxnames/

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.

While poking at the inventory code this morning I found a work-around for renaming “no modify” inventory items.

Aside from being a godsend for inventory organization it would make #RLV folders a whole lot easier to explain, create and maintain (no more having to create separate folders for “no modify” items).

Since it’s technically a bug (the sim/inventory server should be checking that the item is “modify” to match the current viewer behaviour) I’m not going to even consider using it; but it does mean that since LL has to fix one or the other anyway it might be possible to nudge them to “fix” the current default behaviour (which doesn’t allow renaming of “no modify” inventory items) for the better.

https://jira.secondlife.com/browse/SVC-3675 <- vote, vote! :)… Or if you agree with the current behaviour you can voice that

Personally I don’t think they’ll ever get all that much use since they’ll look wrong/silly to everyone who isn’t using Emerald and as soon as people figure that out the appeal of them drops significantly.

Whether or not people will end up using them doesn’t really matter though: at some point or another LL might officially add more attachment points (or clothing layers for that matter) and all the same problems will crop up then anyway so it would be better to try and figure out a way in which scripts can make themselves more “future-proof” now.

After peeking at several “force strip” dialogs most seem to fall into three categories:

• A list of all worn attachment point names spread across different dialogs
• A list of all worn attachment point names divided into categories
• A list of custom grouped attachment points (i.e. clicking “shoes” will force-detach l/r upper leg, l/r lower leg and l/r foot)

So a hypothetical @getattachnames[:<option>] would return a comma-separated list of attachment point names:

• Without  an option it would return all worn  attachment point names
• <option> could specify one of the pre-defined body areas (head, torso, arms, legs  and HUD) and return all worn attachment point names on that area
• <option> could specify the joint name and return all worn attachment point names on that joint

(the “body areas” weren’t really chosen arbitrarily; they’re the same ones you see in the “Attach To” pie menu when you right-click on a rezzed linkset)

(<joint name> wouldn’t be particularly accurate in some cases – “r upper leg” is attached to the “mHipRight” joint along with “right hip” for instance – so it may or may not be a good idea to add that)

Practical example:

• @getattachnames=1
  Skull,Left Foot,Right Foot,Spine,Left Ear,Right Ear,R Forearm,L Forearm,R Lower Leg,L Lower Leg,Top,Top Left,Center,Bottom Left,Bottom,Bottom Right
• @getattachnames:head=1
  Skull,Left Ear,Right Ear
• @getattachnames:torso=1
  Spine
• @getattachnames:arms=1
  R Forearm,L Forearm
• @getattachnames:legs=1
  Left Foot,Right Foot,R Lower Leg,L Lower Leg
• @getattachnames:hud=1
  Top,Top Left,Center,Bottom Left,Bottom,Bottom Right

—

Additionally @getattachnameswearable and @getattachnamesremovable could be added:

• @getattachnames returns the list of attachment point names that are worn
• @getattachnameswearable returns the list of attachment point names that can be attached to (which is any attachment point that doesn’t have a @remattach=n locked attachment *and* isn’t @addattach=n locked)
• @getattachnamesremovable returns the list of attachment point names that can be removed by the issuing prim (which is any worn attachment point that isn’t @remattach=n locked)

The reasoning for @getattachnamesremovable: it’s more intuitive for a “force strip” dialog to only show attachment points that can actually be force-detached by the script.

Practical examples (same as above – l/r forearm and l/r lower leg are @detach=n locked; Top and Bottom Right are “nostrip”):

• @getattachnamesremovable=1
  Skull,Left Foot,Right Foot,Spine,Left Ear,Right Ear,Top Left,Center,Bottom Left,Bottom
• @getattachnamesremovable:head=1
  Skull,Left Ear,Right Ear

—

Finally: there’s the question of whether the script should be responsible for clearing its attachment locks or whether the viewer should just ignore them (the latter is how “Hide Locked Attachments” works).

Example:

• Collar executes: @detach=n,remattach=n
• Collar executes: @getattachnamesremovable=1
  <empty response> since there isn’t a single attachment point that can be @detach[:<attachpt>]=force’d and actually end up detached
• What the collar should have done was:
  @remattach=y, getattachnamesremovable=1,remattach=n
• And then later on:
  @remattach=y, remattach:pelvis=force,remattach=n

It would be easy for the viewer to ignore any @detach[:<attachpt>] and @add/remattach[:<attachpt>] locks though which means it could just go:

• Collar executes: @detach=n,remattach=n
• Collar executes: @getattachnamesremovable=1
  <full list of attachment points that be force-detached by the collar>
• Collar executes: @remattach=y, remattach:pelvis=force,remattach=n

The collar script still needs to know that it should release its @remattach restriction when actually force-detaching but it’s a step in the right direction.

(Personally I think it would make the most sense for @remattach[:<attachpt>]=force to just only check *other* prims’ attachment locks which would mean that @remattach=n,remattach:pelvis=force would “just work” – on the condition that no other prim has “pelvis” locked obviously. It would certainly save scripts a whole lot of hassle)

—

In closing: this is a *proposal* rather than an announcement. Yes the code has already been written, but simply because it’s a lot easier for me to propose something when I know it’ll actually work .

Even if LL decides to block non-standard attachment points with the next rolling restart there will still come a time when we either get new attachment points and/or get multiple attachments per attachment point index so it’s probably best to figure out a solution everyone is – relatively – happy with.

Even if we never get new attachment points it would relieve scripts from having to translate @getattach into a list of attachment point names (less code and no hard coded look-up list should free up some script memory)

Additionally the entire post can be done over for clothing layers: LL supposedly was/is working on extra tattoo layers so when/if we get those all existing scripts that rely on @getoutfit and their hard-coded list of layer names won’t be able to deal with those new layers without an update.

—

Additional thoughts:

• I personally prefer @getattachnames[:[<option>;][wearable|removable]=<channel> over three separate commands (basically making the suffix an additional and optional parameter)
• It might be preferable to fold attachment points together (i.e. Chest and Chest (2) and Chest 2 would all simply report as “Chest” one single time)

Most notable changes:

• added @add/remattach, @viewscript and @viewtexture (RLV-1.22)
• @detach:<attachpt>=n and @addattach[:<attachpt>]=n no longer run the risk of detaching attachments on relog which is a much needed fix
• non-scripted attachments will now reattach properly when accidentally detached (technically it’s any attachment which didn’t change while attached and hence won’t cause a new asset to be created when detached)
• added a convenience feature for “Enable Wear” combined with @addattach: if a “Wear” ends up detaching something on an “addattach locked” attachment point then the old attachment will reattach itself (this is needed since you wouldn’t be able to wear again yourself)
• “Enable Wear” will disable itself when you’re @addattach=n restricted since in that case there isn’t any attachment point that you could wear something on
• reenabled “Copy and Wear” (should have happened in 0.2.2 but I forgot): as with “Add to/Replace Outfit” it’ll work regardless of “Enable Wear” but of course if “Enable Wear” is disabled then it’ll only actually do something if the attachments inside of the object are named properly
• changed “A/This/That human being” to “A/This/That being” (some people felt the former was ill suited for non-human avies)
• “Hide locked attachments” was changed to report from the issuing object’s point of view rather than a global view (see example in release notes)

—

Code downloads:
RLVa-1.0.5e_20091014_SL-1.23.4-full.patch – SL-1.23.4
RLVa-1.0.5e_20091014_SL-1.22.11-full.patch – SL-1.22.11
RLVa-1.0.5e_20091014_Snowglobe-1.1.2-full.patch – Snowglobe-1.1.2

RLVa-1.0.5e_20091014_SL-1.23.4-diff.patch – From 1.0.4e to 1.0.5e (SL-1.23.4)
RLVa-1.0.5e_20091014_SL-1.22.11-diff.patch – From 1.0.4e to 1.0.5e (SL-1.22.11)
RLVa-1.0.5e_20091014_Snowglobe-1.1.2-diff.patch – From 1.0.4e to 1.0.5e (Snowglobe-1.1.2)

Release notes:
release_notes_RLVa-1.0.5.txt

This isn’t as polished as I would like it to be but since Emerald and Imprudence will be doing a new release “very soon” it seemed more important to push this out now rather than hold out.

The primary change is adding the new RLV-1.21 commands (@permissive, the @XXX_sec ones, @versionnum and @defaultwear).

“Enable Wear” remains a user setting (although it is turned on by default now), except when you’re @defaultwear=n restricted obviously in which case the “Enable Wear” option will be grayed out to indicate that it’s being overridden.

One (undocumented) change in RLV-1.21 is that restrictions will be carried over in case of a reattach-on-detach (i.e. if an attachment issues @detach=n,fartouch=n, becomes detached and gets reattached then it will still have @detach=n,fartouch=n set).

I didn’t add this in RLVa though for a number of reasons: every RLV script will already be reinforcing its restrictions in its on_rez()/attach() events to handle relogs so I can’t really see any good reason for it (feel free to poke me if I’m missing something though ). Additionally, scripts that explicitly don’t reinforce their restrictions on attach (because they penalize or automatically unlock on detach for instance) will not be expecting anything but a clean slate in their on_rez()/attach() events so they wouldn’t think to issue @clear on attach and in those cases the user is forced to relog to get rid of stray permissions.

(Sowwies if the above sounds disjointed but I’m sick at the moment )

—

Code downloads:
RLVa-1.0.4e_20091010_SL-1.23.4-full.patch – SL-1.23.4
RLVa-1.0.4e_20091010_SL-1.22.11-full.patch – SL-1.22.11
RLVa-1.0.4e_20091010_Snowglobe-1.1.2-full.patch – Snowglobe-1.1.2

RLVa-1.0.4e_20091010_SL-1.23.4-diff.patch– From 1.0.3e to 1.0.4e (SL-1.23.4)
RLVa-1.0.4e_20091010_SL-1.22.11-diff.patch– From 1.0.3e to 1.0.4e (SL-1.22.11)
RLVa-1.0.4e_20091010_Snowglobe-1.1.2-diff.patch – From 1.0.3e to 1.0.4e (Snowglobe-1.1.2)

Release notes:
release_notes_RLVa-1.0.4.txt

This one has been gathering dust for a while now but I never did seem to get around to releasing it. Bad Kitty, I know .

—

Code downloads:
RLVa-1.0.3e_20091003_SL-1.23.4-full.patch – SL-1.23.4
RLVa-1.0.3e_20091003_SL-1.22.11-full.patch – SL-1.22.11
RLVa-1.0.3e_20091003_Snowglobe-1.1.2-full.patch – Snowglobe-1.1.2

RLVa-1.0.3e_20091003_SL-1.23.4-diff.patch – From 1.0.2c to 1.0.3e (SL-1.23.4)
RLVa-1.0.3e_20091003_SL-1.22.11-diff.patch – From 1.0.2c to 1.0.3e (SL-1.22.11)
RLVa-1.0.3e_20091003_Snowglobe-1.1.2-diff.patch – From 1.0.2c to 1.0.3e (Snowglobe-1.1.2)

Release notes:
release_notes_RLVa-1.0.3.txt

“Outfit snapshotting” is maybe best compared to SL’s native “Create Outfit” feature: when you create an “outfit snapshot” the viewer iterates over every layer and attachment point and stores what item is currently worn there (if any at all) so that you can instantly change back at a later time, but without the inconvenience of needing to have everything in one folder.

I created it back when I was testing all the force stripping and force dressing commands since I was becoming increasingly frustrated with having to constantly change back to what I was wearing before after each test.

As you might guess the feature is primarily one of convenience: if you just went shopping you could “snapshot” your current outfit and just try things on and just instantly snap back to what you were wearing before if you’d want to. Or if an object just offered you an #RLV/~ folder (or if you’re trying one of the vexation curses) you could quickly “snapshot” what you’re currently wearing and change back later if it turned you into something weird (or replaced your skin/shape/clothes/etc).

One of the reasons why I never turned this into an actual feature is because I never did really come up with a good way to make this available in the general case. Should “outfits snapshots” be created from a menu, a keyboard shortcut, or would it just be easiest to expose it to scripts so they can worry about how to solve that problem?

Another problem was one of storage: storing them on your puter would mean that you wouldn’t be able to access them from a different one (or worse they would become out of sync) which is clearly not desirable which means they have to be stored in your inventory *somehow*.

The fact that LL seems to be working on inventory hardlinks (an inventory item that acts as a shortcut to another inventory item or a folder) means that the best solution is probably a folder hierarchy since then the viewer can take advantage of the new asset types when they’re available (in the meanwhile empty notecards would serve the same function, primarily because as far as I know an empty notecard inventory item doesn’t result in creating a new asset so it wouldn’t unnecessarily tax the asset system).

With all that said the following two questions still remain:

1. While I’m fond of the feature is it actually something anyone else would find useful to have?
2. If so then how would you prefer to both create and restore an outfit snapshot? (ie a menu option somewhere, a new floater, keyboard shortcuts, etc)

(Or there might be additional things I never even thought of )

“I cannot get changed: the ‘Wear’ option is grayed out when I try to wear something”
“When I look at the owner of a prim it says ‘Someone’ or ‘Some People’ instead of an actual name. What is going on?”
“I can’t left-click or select anything anymore and it’s driving me crazy!”
…

Given the context of the blog it’s clear that an RLV restriction is the cause of what’s happening but what makes these questions so peculiar is that there’s never any mention of RLV, nor are they even asked in places where there’s a high chance of someone being able to properly identify it as being RLV-related (a general group in-world, the forums or even on JIRA).

While the problems above will very likely be obvious to anyone who’s had RLV enabled for some time even long-time users might stumble across something they won’t instantly attribute to RLV. As an example: how many RLV users will realize that the reason their teleport offer to a friend is silently failing is because they’re currently @showloc=n restricted which means that they can only offer a teleport to someone who’s a @tplure exception?

The topic of this blog post (and the aim of the proposed feature) is some way to try to make it more obvious to someone when a certain behaviour is due to some restriction rather than an actual bug or general “SL borkiness”.

It would probably also be very helpful to a lot of people if someone (or a group of people) could find the time to create a section on the SL wiki that explains some of the common pitfalls or even just an up-to-date tutorial on how set up the shared inventory (or how to name attachments so that they’ll be “Wear”’able).

If I had more time – or was any better at explaining things in a way that makes sense to other people – I’d try to at least lay the foundation but I’m just not terribly good at that kind of writing .

What I can do and what I thought might be equally helpful is to add a number of “first use” popups that on the one hand provide a clue that something “unusual” just happened and on the other hand would refer to the wiki pages for more (detailed) information.

@fartouch=n "First use" popup

It’s obviously not the intention to bombard RLV users with popups for every single command but to limit it to those cases which are either the most unintuitive (no longer having “Wear” when something is locked on) or which cause the most confusion (@fartouch=n).

So far the list includes:

• The first time an attachment is locked (highlights that the “Wear” option on attachments will no longer work unless they’ve been named properly)
• The first time someone is fartouch restricted (short explanation along with a tip on how to tell when something is too far away)
• The first time someone receives an #RLV/~ folder (offers to enable the “Give to #RLV” feature or keep it disabled)

Other suggestions:

• A popup offering to go o a page on the wiki that contains a short summary of what a new RLV user can expect along with a FAQ that covers most of the stumbling blocks
• When an #RLV folder is created there could be a popup offering to go to a page on the wiki that contains a tutorial and some “best practices” for shared inventory

If you have any related comments (whether it’s an “I like it” or “I hate it” or “maybe also have a popup when….”) please do make them either here or in IM or a notecard in-world .

Without feedback it’s always hard to know whether something might indeed be useful, or whether there even is a large enough portion of people who would actually benefit to make the time spent on it worthwhile.

Nothing special about this one other than a few bug fixes so there really isn’t much to say .

At this point 1.1 is mostly some code refactoring that noone is really going to care about so I’ll write another blog post sometime this week about some features that never did make it into a public release and ask whether anyone sees anything they’d really like to see merged back in.

—

Code downloads:
RLVa-1.0.2c_20090909_SL-1.23.4-full.patch – SL-1.23.4
RLVa-1.0.2c_20090909_SL-1.22.11-full.patch– SL-1.22.11
RLVa-1.0.2c_20090909_Snowglobe-1.1.2-full.patch– Snowglobe-1.1.2

RLVa-1.0.2c_20090909_SL-1.23.4-diff.patch – From 1.0.1h to 1.0.2c (SL-1.23.4)
RLVa-1.0.2c_20090909_SL-1.22.11-diff.patch – From 1.0.1h to 1.0.2c (SL-1.22.11)
RLVa-1.0.2c_20090909_Snowglobe-1.1.2-diff.patch – From 1.0.1h to 1.0.2c (Snowglobe-1.1.2)

Release notes:
release_notes_RLVa-1.0.2.txt

There isn’t anything new compared to RLVa-1.0.0 since I really did want to focus on bug reports only (and there really wasn’t all that much RL time to work on anything else either ) so I’ll just do a quick overview; you can read the change notes if you really want all the boring details .

—

Support for “legacy naming” of folders was added (see the two relevant blog posts for the long winded explanation) which means that in addition to “.(attachpt)” the following folder names will now work as well:

• (attachpt)
• attachpt
• .attachpt
• Something (attachpt)

In addition those folders will be hidden from @getinv and @getinvworn even if they don’t specifically start with a dot which should cause less confusion for scripts and people alike.

Hopefully this change will be a better compromise between being unambiguous and being compatible with how some people named all their folders already.

(If all your folders are already “strictly named” then you can just set RLVaEnableLegacyNaming to FALSE)

And of course a big thankies to Sei for bringing up the issue in the first place and then being patient enough to go through several iterations of suggestions .

—

@attach:<folder>=force was only performing a “starts with” match as opposed to a “contains” match which caused problems for at least one “force wear” script.

Thankies to Shuggi for reporting this.

—

Add, remove and force commands are no longer held pending execution until the object finally rezzes. While this didn’t actually lead to breaking any scripts, there was one specific restraint that would “spam” the wearer incessantly until the attachment finally rezzed (due to @getstatus being empty since the restrictions were “pending”).

Thankies Garvin for reporting this.

—

Script offered “#RLV/~Something” inventory would sometimes seemingly fail (depending on the number of the items that were being offered) to rename the folder and that’s been fixed as well.

Thankies to Eglan for first reporting the bug and thankies to Tammy for having a solid repro.

—

When @shownames=n restricted the name tags wouldn’t be hidden but would just show the – filtered – name of each avie. This was intended to be helpful to people who didn’t know they could just hover their mouse over someone to see which name corresponds to which avie (or situations where mouse hovering wasn’t possible, ie blocked by a HUD).

However it turned out that some people do enjoy the “guessing game” and felt cheated out of having the choice to see which anonym corresponds to which avie or not.

As a compromise name tags will no longer show when @shownames=n restricted by default but they can be toggled back on by setting RLVaShowNameTags to TRUE (which makes showing name tags subject to the default Edit / Preferences / General – Show Names preferences).

(If chat bubbles are enabled then the filtered name will appear in the bubble though, regardless of RLVaShowNameTags)

Thankies to Tammy for bringing this up.

—

All worn items will be fetched from inventory at log-on which means that “nostrip” will no correctly work regardless of whether your inventory is fetched or not (was one of my major pet peeves so I’m happy I got this one fixed ).

(If you’re using a viewer with a “Worn” inventory tab you’ll have the side-benefit that it will be instantly populated even if you just did a “clear cache relog”)

—

@detach:<attachpt>=n and @notify:<option>=add were added as new commands due to RLV-1.20.

The former can still cause an attachment on “attachpt” to be forcefully detached at logon if there is particularly bad lag (or if you’re connecting from a low bandwidth connection) but hopefully it shouldn’t be quite that common.

(I should point out that the opposite is possible too: at log-on you have a “small” window where you can attach something to an attachment point that’s supposed to be locked empty. If people run into that accidentally then I might disable wearing anything until the window has passed but only time will tell)

Additionally I think I addressed all conflicts that can occur between @detach=n and @detach:<attachpt>=n (you can look at the test cases in the release notes in case I missed something).

—

Code downloads:
RLVa-1.0.1h_20090812_SL-1.23.4-full.patch – SL-1.23.4
RLVa-1.0.1h_20090812_SL-1.22.11-full.patch – SL-1.22.11
RLVa-1.0.1h_20090812_Snowglobe-1.1.2-full.patch – Snowglobe-1.1.2

RLVa-1.0.1h_20090812_SL-1.23.4-diff.patch – From 1.0.0h to 1.0.1h (for SL-1.23.4)

Release notes:
release_notes_RLVa-1.0.1.txt

I also kept getting sporadic reports of reattach-on-detach failing to reattach a locked item (or reattaching some but not others) and spent a lot of time in the past week trying to repro it since it really is something that really needs to be reliable and while I did find two related bugs (one which has been fixed and one that will be fixed) it’s extremely unlikely that anyone was running into those.

It wasn’t until I took a little break to clear my head that I finally realized what was happening… The problem isn’t the viewer at all, but it’s because some scripts issue “@clear” when detached (and of course none of the ones I was testing with did that) which results in the following sequence of events:

1. Attachment becomes detached (due to llAttachToAvatar() for example)
2. The script’s “attach(key kId)” event fires with “kId == NULL_KEY”
3. The script issues “@clear”
4. The viewer receives “@clear” and clears *all* of the attachment’s restrictions
5. The viewer receives a “KillObject” message for the attachment and kills the object
6. The viewer checks whether the attachment was locked when it got detached and doesn’t find a “@detach=n” restriction – @clear removed it in (4) – so it isn’t going to reattach it

I realize that the specification/API page specifically tells script creators that issuing @clear on detach is something they should always do but it completely disables the reattach-on-detach feature in both RLVa *and* RLV for that attachment.

I’ve had enough people pass me several freebies that will “force-detach” any locked attachment (and there are stores that sell gadgets like it as well) to know that pretty anyone who wants to has easy access to an llAttachToAvatar() script so even leaving “Enable Wear” aside reattach-on-detach really isn’t something that scripts should be disabling for themselves.

All in all there really isn’t that much that can be done about the problem from the viewer’s side: the script needs to be updated to not issue @clear on detach (or only issue @clear on detach when it’s not locked) in order for reattach-on-detach to work.

Technically there’s no real need for @clear on detach either:

• RLVa will issue @clear on behalf of the object as soon as it becomes detached
• Both RLVa and RLV regularly clean up restrictions that were issued by objects that no longer exist (on RLVa that happens every 30 seconds, on RLV it happens every 600 frames)

The good news is that all the issues that were brought up have been fixed and the new RLV-1.20 commands have been implemented as well. 

The bad news is that I haven’t had the time to thoroughly test the former and that the latter introduces a showstopper bug due to the way @detach:<attachpt>=n was defined (note that this isn’t specific to RLVa).

Specifically “If the point is empty it will stay that way, no item will be able to be attached there, and llAttachToAvatar() calls will fail (the object will be attached, then detached right away).” (quoted from the RLV API wiki page) introduces a race condition.

An example:

1. Object A (attached anywhere but spine) locks the spine attachment point with @detach:spine=n and reinstates that command on every log-on
2. Object B is a random object that’s attached to spine (could be a collar for instance)

When you log on:

• Time A: Object A issues @detach:spine=n
• Time B: the viewer receives the message that there’s an Object B that should be attached to spine

As long as B occurs before A there is no problem, but if A occurs before B the following happens:

1. Viewer receives @detach:spine=n (Time A)
2. Viewer attaches Object B to spine
3. Viewer detaches Object B because spine is “locked empty” by Object A in (1)

Or in other words: if there’s the slightest bit of lag when you’re relogging there’s a decent chance that instead of locking the attachment point @detach:<attachpt>=n will actually end up *detaching* the attachment you wanted to make undetachable with no way to get it reattached (relogging with the regular viewer isn’t much of a help either since on the next RLV-enabled relog the same thing could happen).

I *think* I have a workable solution right now but I won’t have time to thoroughly test it until Friday so there won’t be an RLVa update until late in the weekend most likely, sowwies .

▼ #RLV
  ▼ >Gags
    ▼ Ball Gag
      ▼ .(mouth)
        |-> Ball gag
    ▼ Duster Gag
      ▼ Duster Gag (mouth)
        |-> Duster gag
    ▼ Ring Gag (mouth)
      |-> Ring gag

There are a few assumptions we can make about the above folder layout:

• the “>Gags” folder is clearly a category folder with no other purpose than to keep things tidy and sorted
• as such the “>Gags” folder has no direct child items (the first number of @getinvworn should be ‘0′)
• but it does have three child folders (@getinv should return “Ball Gag, Duster Gag, Ring Gag (mouth)”)
• all three “XXX Gag” folders should look the same to scripts since even though they each use a different naming scheme they’re all essentially the same (one no modify indirect child item that happens to be in a folder that specifies its attachment point)Or in other words:
  • @getinvworn:>Gags/XXX Gag=1 should return |10 (assuming everything is unworn)
  • @getinv:>Gags/XXX Gag=1 should always return an empty response (no gag folder has a real child folder, they’re all attachment indication ones)
  • @attach:>Gags/XXX Gag=force should force attach the gag

If you’re nodding along with a “that’s correct”: it *should* be correct, but unfortunately there is no way I can see that you’d be able to get that behaviour since in the above example the “Folder name (attachpt)” convention is used twice in completely different ways.

You can create the above structure in “RLV proper” and try it for yourself and follow along if you want:

1) @getinvworn:>Gags=1
Expectation: |01,Ball Gag|10,Duster Gag|10,Ring Gag (mouth)|10
Actual result is: |11,Ball Gag|10,Duster Gag|10,Ring Gag (mouth)|n

What’s happening:
- since the “Ring Gag (mouth)” folder specifies an attachment point name the item it contains is folded under the parent instead (the “>Gags” folder)
- “Ring Gag (mouth)” is empty as far as RLV is concerned and shouldn’t be exposed to scripts which is why it’s returning the invalid ‘n’ value (seems to be ‘N’ when the item under that folder is actually worn)

2) @attach:>Gags=force
Expectation: nothing, it’s just an organizational folder
Actual result: the ring gag gets attached

What’s happening:
- the explanation above covers it: RLV is treating the ring gag attachment as belonging directly to the >Gags folder

3) @getinvworn:>Gags/XXX Gag=1
Expectation for all three: |10
Actual result:
@getinvworn:>Gags/Ball Gag=1
|10
@getinvworn:>Gags/Duster Gag=1
|10,Duster Gag (mouth)|n
@getinvworn:>Gags/Ring Gag=1
|n

Only the “Ball Gag” returned the expected result (the subfolder in Duster Gag should not have been visible and even if it is it should have indicated |00 and Ring Gag just returned an entirely invalid result).

4) @attach:>Gags/XXX Gag=force
Expectation for all three: the gag contained in that folder should attach
Actual result:
@attach:>Gags/Ball Gag=force <- attaches the gag
@attach:>Gags/Duster Gag=force <- attaches the gag
@attach:>Gags/Ring Gag (mouth)=force <- does nothing

However, since the “Ball Gag (mouth)” folder is exposed to scripts (in both @getinv and @getinvworn) it’s likely that if someone is browsing through the folders that they’d enter that folder and that the script would issue:
@attach:>Gags/Duster Gag/Duster Gag (mouth)=force <- does nothing

Out of the 5 assumptions we started out with only one actually holds true (“>Gags has three subfolders”), but all the others either always broken or half broken (it will work on some occassions but not others).

“Folder name (attachpt)” is clearly *not* the way to go when it comes to the #RLV shared folder and scripts, but unfortunately is how the first “Object Sharing” tutorial is telling people to name their folders that way.

Which leaves an almost “no win” situation, something gets broken no matter what:
- if it’s allowed, RLVa would exhibit similarly broken behaviour as described above
- if it’s not allowed then people need to rename all their folders

So with that in mind:
- anything named *exactly* like the first “Object Sharing” tutorial tells you (Item name follwed by a space followed by the attachment point name in parenthesis) to will silently act if that folder was called “.(attachpt)”
- anything not named like that will act like a visible folder that happens to contain the attachment point name of where the item(s) inside of it should attach to

—

An alternate solution (which is looking very tempting right now):
- instead of merely acting as if that folder was called the proper way (ie “.(attachpt)”) the viewer could actually rename it that way

Ie:

▼ #RLV
  ▼ >Gags
    ▼ Ball Gag
      ▼ .(mouth)
        |-> Ball gag
    ▼ Duster Gag
      ▼ Duster Gag (mouth)
        |-> Duster gag
    ▼ Ring Gag (mouth)
      |-> Ring gag

would be auto-renamed to:

▼ #RLV
  ▼ >Gags
    ▼ Ball Gag
      ▼ .(mouth)
        |-> Ball gag
    ▼ Duster Gag
      ▼ .(mouth)
        |-> Duster gag
    ▼ .(mouth)
      |-> Ring gag

While this clearly “breaks” the name of the ring gag folder, that folder was already hopelessly broken (its name unintentionally happened to follow the outdated naming convention). The change would hopefully make it clear to the user that *something* is wrong.

(The main advantage is that is it’s far less code to write and in an entirely different place so the chance of inadvertingly creating new bugs is quite low. The main disadvantage is that some people might feel the viewer is messing up their folder names)

—

Hopefully this concludes this “series” of blog posts where page upon page was written – here and on the thread – over what amounts to a mere 10 lines of actual code .

When I originally looked into shared folders (3 seasons ago now) the tutorials on Marine’s blog seemed relatively straightforward to me:

• If the item is “modify” then append “(attachment point)” to its name, ie: “Collar (chest)
• If the item is “no modify”, place it under a new folder with the name “.(attachment point)”

RLV does actually accept variations that are much looser than that and it seems that (some) people either took advantage of that, or took the tutorials’ text to mean that neither the parenthesis (nor the prefixed dot for folders) were part of the convention and that anything that the viewer would accept was “legal”.

(At this point I should point out that I’m quite obviously biased on my personal interpretation so if I end up phrasing things in a way that reads like I’m doing a “I’m right and you’re wrong” please don’t take it as such. I do respect everyone’s differing interpretation or I wouldn’t be putting nearly as much time into this as I am/have/will)

One of the major advantages of observing the (what I’ll dub “strict”) convention shown in the screenshots is that it’s almost completely unambiguous and is very unlikely to lead to false positives.

The reason why false positives are even a problem is: if the viewer ends up attaching something to the wrong attachment point then the positioning is irrevocably lost. Reattaching it to where it’s supposed to go means you have to adjust the attachment (something which a great many people seem to have an incredibly hard time with). The 1.23 viewer also removed the fail-safe ability to copy/paste the item to avoid having to reposition it (although some third-party viewers re-enabled that it can no longer be counted on to work for everyone).

While I can only hope that people will shy away from the “loose” convention in favour of the “strict” naming convention (regardless of which RLV implementation they use), the primary purpose of this post is how to handle the case where people currently have folders that don’t mean the “strict” requirement.

—

“No rules of any kind” (= “the RLV default):

• the name is searched left-to-right
• *and* attachments with a lower attachment ID take precedence (you can find those at http://wiki.secondlife.com/wiki/Llattachtoavatar )

Practically:

• “Keri – Chestnut (skull)” will attach to “chest” (1) rather than the expected “skull” (2)
• “Skull Necklace (spine)” will attach to “skull” (2) rather than the expected “spine” (9)
• “(spine) Skull Necklace” will still attach to “skull” (see the IDs above)

“Search right-to-left” and “ignore the attachment id precedence”:

• “Keri – Chestnut (skull)” will attach “skull” as expected
• “Skull Necklace (spine)” will attach “spine” as expected
• “(spine) Skull Necklace” will still attach to “skull”

A lot better already, but also consider the following example:

• “drawmachine overknees small L foot” will attach to “chin”

“Search at the word boundary”:

Better still, alas:

• “[PM] Posh Boots Leather- Black – Upper Left Foot” will attach to “left foot” even though I’d realize that “upper left foot” really means “l lower leg”
• “Emotional Warfare – Longsleeve Top (Upper R)” will attach to “HUD Top” (dependant on your own inventory but having “Top” in the item name is incredibly common)
• “*Le Vixen Coat Bottom” (as is “Bottom”)

“Specify the attachment point in between ()”:

And we’ve reached the “strict” convention as far as item names are concerned.

—

If you do the same exercise over for folder names you end up at the same conclusion: append the attachment point at the end and in between parenthesis.

In a lot of cases though the above doesn’t really work folders because you’d only need to rename them for a no modify item and in that case there can only be one item under that folder so you end up with “(attachpt)”. (I should point out that some people use “attachpt” as well, and others use “.attachpt”)

All in all we end up with five different ways to name a folder that are good candidates for not being too ambiguous on where the items inside of them should go:

1. .(attachpt)
2. (attachpt)
3. .attachpt
4. attachpt
5. Whatever you want here (attachpt)

Folders can also be used in one of two ways:

• a) Anywhere random in your inventory (named primarily for your convenience)
• b) Under your #RLV shared folder (named primarily for the convenience of script usage)

So let’s look at each of them separately (since they unfortunately both have different requirements):

a) For your convenience: in this case the name is what you see and what you’ll have to work with yourself so you want it to be practical and ideally look pretty (ok, fine, it’s what I want from my folders, play along ).

Some practical examples (assume everything we create a folder for is no-modify):
▼ Themed
    ▼ Playboy Bunny – Black
        ▼ .(chin)
             -> ears
        ▼ .(pelvis)
             -> bunny tail
         -> clothing layers

▼ Gags
     ▼ Duster Gag
          ▼ .(mouth)
           -> actual gag

Trying to looking at it from someone else’s point of view the “duster gag” layout is probably “impractical”, “complicated” and/or “ugly”.

There’s probably no real good reason not to allow (5) from above to make:

▼ Gags
     ▼ Duster Gag (mouth)
      -> actual gag

With the bunny outfit there’s no way around creating subfolders but again there’s probably no good reason to insist on (1). “(chin)”, “.chin”, “chin” and “Bunny Ears (chin)” are all unambiguous too.

So in the specific case of folders for “personal use” the following variations are probably safe:

• appending the attachment point to the name of the folder
• the name of the folder exactly matches an attachment point name (after discarding any pre-pended ‘.’ or surrounding parenthesis)

Personally I would still only recommend people use (1) and just silently have (2), (3) and (4) for “backwards compatibility/convenience to people who already named their folders that way”

b) When it comes to folders that exist under your #RLV things are – unfortunately – slightly different. The names of them should chosen primarily to be friendly for scripts (who are stuck with a limited llDialog) and not clutter things up unnecessarily (avoid showing folders that the script doesn’t need to know about).

Let’s look at some “over the knee” boots (with each attachment point differently named):

▼ Overknees
    ▼ .(left foot)
    ▼ (right foot)
    ▼ .l lower leg
    ▼ r lower leg
    ▼ wear on (l upper leg)
    ▼ wear on r upper leg

Please note that the last one (“wear on r upper leg”) is still going to be illegal since it has neither parenthesis, nor is the entire name an attachment point (scroll up if you need a reminder why ‘we’ decided that “partial matching” is a bad idea).

Anything but (1) and (3) really aren’t “script-friendly”. If a script browses your inventory it would learn that the folder “Overknees” has 4 sub-folders “(right foot)”, “r lower leg”, “wear on (l upper leg)” and “wear on r upper leg).

To be fair RLVa *could* be changed so that it won’t report any of those since they’re not really subfolders but “attachment point labels”, but it’s still not good practice (RLV does report them which causes bugs of its own when it comes to @getinvworn).

Personally, I don’t like (3) “.l lower leg” because it makes the definition of a “hidden folder” more complicated: “any folder that starts with a dot and doesn’t specify an attachment point name either in parenthesis or without them”. While that might seem “no big deal”, it’s less obvious on a folder called “.Top” or “.Bottom” for instance.

Which technically leaves us with just (1) and we’ve arrived at the “strict” convention for folders too.

—

So all of that to explain why – in my personal opinion – the “strict” naming convention is really the only one I can think of that doesn’t introduce “undesirables” of some kind.

Obviously that doesn’t help people having “non-conforming” folder names, so I would like to propose:

• For items I can’t see any workable solution other than “strict”. Any deviation leads to some bad side-effects. Luckily I think the overwhelming majority of people does follow the parenthesis convention here (if you don’t, please, please speak up)
• For folders allow (1) through (5) which should hopefully cover most of everyone

So what it wouldn’t cover is for instance an item (or folder) called “Something (worn on l forearm)” or “Something l forearm”.

Lastly I would really like to thank Sei Lisa for bringing up the issue in the first place and for spending all the time she has so far reading and responding to posts on that thread ( http://modularsystems.sl/index.php?option=com_agora&task=topic&id=298 – registration required, sowwies).

Work has been particularly bad the last week (work and me seem to have a very different idea of what “flexible hours” actually means) so nothing new RLVa-wise.

Since I only had about an hour each day I thought it could be a good opportunity to fix some minor/trivial SL bugs that had been annoying me for a while (ironically making all the diffs and submitting them took more time than fixing it in the first place and was definitely not “fun”).

Minor does actually mean minor, but here’s the list in case anyone sees something they want to vote on (patch was attached to the issue as VWR-xxx.diff in each case):

• VWR-14765 - Viewer crashes when quitting from the login screen while the focus is on the grid selection combobox
• VWR-10780 - Take off Items inventory folder option removes eyes
  (This one is actually in RLVa already but it seemed like a good time to actually drop it on JIRA as well)
• VWR-14766 - Separators aren’t skipped when navigating a menu with the up arrow
• VWR-5063 - Cannot attach multiple objects via wear
  (Patch will need some additional work if you include it in an RLV/RLVa viewer)
• VWR-7241 - Communication window is not keeping its minimized state after going into Mouselook
• VWR-2485 - Pie menu remains after switch to Mouselook
• VWR-14767 - Closing the build floater in mouselook doesn’t select the proper toolset
• VWR-4212 - Cannot drop object onto land if group-only object create/object entry is enabled (reopened because this wasn’t fixed for group-owned land)
• VWR-14666 - Mouselook gets stuck in an intermediate state when switching away and back from full-screen
• SVC-4128 - llTakeControls(*,FALSE,TRUE) prevents left clicks from mouselook.

1) Unset restrictions

1. Object failed: @clear
2. Object failed: @showinv=y,showminimap=y,showworldmap=y

(The first one in particular seems to cause confusion)

When a “remove” command (=y or =rem) is received the issuing object is looked up and if it exists it will have the corresponding restriction lifted.

If the issuing object doesn’t exist as far as RLVa is concerned (because it never set any restrictions for example) then @clear would get reported as “failed” because there is nothing to be cleared.

Similarly, the commands in (2) would all fail if the object never did set those restrictions in the first place (or it set them, unset them and then tried to unset them once more).

From my point of view it’s expected behaviour, primarily because if command processing didn’t out bail out at that point then undesirable things would start happening.

Ironically it’s that “failsafe” that leads to “oh ok, but really it’s a harmless command so why report it as a failure?”.

2) Duplicate restrictions

A prim can only ever hold a restriction once, so if a script issues @detach=n and then later – for whatever reason – issues another @detach=n then the second will be reported as a failure because that particular restriction is already held by that prim.

From my point of view a failure is once again expected behaviour since if it didn’t fail then “detach” would be set twice for the same prim and it would take two @detach=y to clear it rather than the one that’s expected.

I do realize that from someone else’s point of view the second @detach=n might just be seen as harmless and nothing that should be complained about.

—-

I don’t actually have any personal preference on what it should be reporting to other people though. I can keep it the way it is for personal debugging, and report something else that is more meaningful (to scripters for instance) on a release build .

There do however seem to be some varying opinions on what would be “the right way” to report on command processing so if someone wants to provide any feedback please indicate what you would you expect (or prefer) to see in the following cases:

1. unset (ie @showinv=y without a previous @showinv=n)
2. duplicates (ie @detach=n,detach=n)
3. misspellings or non-existant commands (ie @remouftit=n or @abcdef=n)
4. blocked commands (ie @remoutfit:shirt=force while a different object has @remoutfit=n set
5. undefined commands (subtle variation on 3), ie @redirchat=n or @sittp:<uuid>=add
6. invalid parameters (ie @redirchat:a=add or @tpto:Ahern/128/128/20=force)
7. anything else I might have missed

(If you’d rather drop me a notecard in world that’s fine too . I know I never like giving my email addie to “some random blog” just to comment, but I’m not actually sure how to turn that off )

To be fair, sometime between that Friday and Sunday I made the decision that for the big “1.0” I wanted to at the very least verify all RLVa code that lives outside of the rlv* h/cpp files to reduce future merge conflicts and that ate up quite a bit of time .

The end result is a lot of (relatively minor) bug fixes and a few notable changes (check the release notes for the full boring list of changes):

• The occasional “phantom wearing” bug that kept me from re-enabling “Add to Outfit” and “Replace Outfit” is fixed so “Add to Outfit”, “Replace Outfit” and “Take Off Items” are available regardless of whether you currently have any locked attachment(s)
• As a side-benefit drag/dropping a folder (= “Replace Outfit”) and “Copy and Wear” (= “Add to Outfit”) are re-enabled as well
• Drag/dropping an attachment from inventory onto your avie is re-enabled as well. If “Enable Wear” isn’t checked it will only attach if the name (or the name of its parent folder) specifies an attachment point name
• Re-enabling the “Start Location” is fixed as well (weird things happen when you mix up TRUE and FALSE )
• RLVa specific options (under the Advanced / RLVa sub-menu) will persist across relogs

Changes to RLV functionality (compared to RLVa-0.2.2):

• @showloc=n will replace any occurance of surrounding region names as well
• @recvchat=n will no longer truncate emotes depending on whether @emote=add is set or not, and neither will “special characters” discard the entire emote. This was done primarily because this behaviour was never documented anywhere, and no one I ever asked either knew about it or expected @emote=add to influence how @recvchat=n worked
• @setrot:=force is “fixed” to conform to the RLV spec. For all of SL a rotation of 0.0 around the Z-axis ends you facing East (positive X) but the RLV spec defines a rotation of 0.0 as facing North (positive Y) for some reason
• @fartouch=n will no longer show a pie menu if you can’t use any of the options anyway (was a big pet peeve of mine )
• @shownames=n was extended to cover a few more SL features that expose the names of nearby avies

I do still need to go over some code in the rlv* h/cpp files (mostly inventory related commands) and I’ll release another update once that’s done, but – crosses fingers – hopefully nothing major will turn up in that review.

Moving forward, I’ll take special care to provide each new update as both a full diff against the official viewer source and a partial diff against the last released version so that keeping up with updates will hopefully become a lot less time-consuming and frustrating.

To the extent possible I’ll keep providing RLVa against the current main viewer (currently 1.23.4), the previous one (1.22.11) and an upcoming one (1.24 RC when it comes out).

And last but not least, a big bag of choc-chip cookies and huge huggles to Satomi for poking and prodding me for the past few months, for offering suggestions and feedback, providing me with “yet another thing GCC doesn’t like”, and most of all for listening to me ramble away. She also makes a far better RLVa-evangelist than I do so: thankies Satomi!

Special thankies to Eglan as well for taking the time to figure out how to compile the viewer on his Mac and subsequently testing RLVa on that platform as well .

Code downloads:
RLVa-1.0.0h_20090712_SL-1.23.4-full.patch - SL-1.23.4
RLVa-1.0.0h_20090712_Snowglobe-1.0.2-full.patch - Snowglobe-1.0.2
RLVa-1.0.0h_20090712_SL-1.22.11-full.patch - SL-1.22.11

Release notes:
release_notes_RLV-1.0.0.txt

Of course they’re free to want to do it themselves, but certainly at this point plenty of silly little things get changed around in the code and having to spend time resolving rejects of tidbits of code you didn’t write (or know the bigger context of) each time I update something can get tedious very quickly.

On the other hand if I’m maintaining a viewer-specific patch I can incrementally merge in smaller changes which is something I have to do for SL-1.22, Snowglobe-1.0 and the “experimental” RLVa branch anyway so one more or less isn’t going to make that much of a difference .

I did a Green Emerald specific patch today which should patch cleanly against the “206 version”. Since I haven’t ever used that particular viewer before it’s hard to know whether every feature it has that might impact RLV functionality has been made “RLV-aware” and I would like a bit more time with it to “sign off”, but it’s definitely useable as-is.

List of feature-specific changes (ie not just resolving a reject):

Double click wear (due to @detach=n on any attachment)

• no changes needed, works as-is

Double click teleport

• no changes needed, works as-is
  (double click teleport will be tied to @tploc=n due to LLAgent::teleportViaLocation())
• preferred: tie double click teleport to @sittp=n (to do)

Avatar List Feature (due to @shownames=n)

• floater closes if currently open
• toolbar button disables as a visual cue
• menu option doesn’t have an enabler function to visually disable
• chat announcements are disabled (could re-enable with “anonyms” but seems silly?)

Teleport History Floater (due to @showloc=n)

• populates new entry with “(Hidden)” fields
• relevant buttons disable when a “filtered” entry is selected to avoid confusion

IM auto response (due to @sendim=n restricted)

• auto response will not be sent (could be handled differently?)

Download:
RLVa-0.2.2b_20090703_Emerald-206-full.patch

I’m really hesitant to name a time-frame for it since I haven’t quite met all the last ones :p, but I have tomorrow off (though not Saturday) so I’ll have 2 days before the end of the week where I can still get things done so probably expect *something* by Monday evening (coding will probably stop on Sunday but that leaves me Monday evening to do some “cleaning” and to make sure all the other branches are up-to-date as well).

Compared to 0.2.1d there really isn’t much of note in 0.2.2a other than that it’s the first one to get posted here on the blog.

“Add to Outfit” and “Remove Outfit” were re-enabled but since there was some oddness going on (might have been due to the fact that LL lets “Take Off Items” remove the eyes which seems to lead to some baking oddness) that’s been turned back off until that’s fixed.

I kept putting off implementing “Give to #RLV inventory” (not sure what to call that particular feature) but it’s finally there now and the primary reason for doing another release. I think it marks a full implementation of the RLV specification now too .

Lastly, there was a teaser about (some of) the new 1.19 RLV specification commands on Marine’s blog last night and those are implemented in advance of an actual release as well with the understanding that they’ll likely need some changing once it’s clear exactly how they’re supposed to work but they should be “close enough”.

@recvemote[:<option>]=n and @rediremote:<option>=add are probably good as-is

@showhovertextall=n is *probably* good as-is as well

@showhovertext[:<option>]=n was a wild guess on my part:

• @showhovertext[:<attachpt>]=n will hide any hovertext on object attached to “attachpt”
• @showhovertext[:<uuid>]=n will hide any hovertext on the prim specified by “uuid”
• @showhovertext=n will hide any hovertext  on the issuing prim (by uuid, not by attachpt)

@showhovertexthud=n was a wild guess as well and will hide all hovertext on any prim of any HUD attachment

For now there’s just an SL-1.23.4 patch, I’ll probably get Snowglobe and SL-1.22.11 patches done either later tonight or sometime tomorrow.

Update: sorry for the inconvenience, but GCC choked on one line so the new version is now 0.2.2b and should compile cleanly on Windows and Linux now (thankies muchies Satomi). If you already used the full RLV-0.2.2a path there’s a diff between ‘a’ and ‘b’ available below.

Code downloads:
RLVa-0.2.2b_20090702_SL-1.23.4-full.patch - SL-1.23.4
RLVa-0.2.2b_20090702_Snowglobe-1.0.2-full.patch – Snowglobe-1.0.2

RLVa-0.2.2b_20090702_SL-1.23.4-diff.patch – RLVa-0.2.2a to 0.2.2b
RLVa-0.2.2a_20090702_SL-1.23.4-full.patch – RLVa-0.2.2a (obsolete – see above)

Release notes (including the previous versions for reference):
release_notes_RLV-0.2.2.txt
release_notes_RLV-0.2.1.txt
release_notes_RLV-0.2.0.txt

While it’s possible to make – or buy – a script that locks either a clothing layer or an attachment to prevent it from getting stripped by RLV it does come with some drawbacks of its own: it removes the “Wear” option on attachments (for those who don’t habitually have other locked attachments), prevents easy dressing or changing since the attachment or layer needs to be unlocked before you can wear something else in its place, is simply not an option for “no modify” attachments and perhaps most importantly you have to remember to lock it in the first place (especially inconvenient when it comes to layers).

RLVa allows you to mark a clothing layer, attachment or an entire folder as “don’t strip” simply by appending “nostrip” to its name. While no RLV attachment or device will now be able to strip it off you, it differs from the script-based approach in that *you* can still take it off or wear something else in its place.

There is however one significant drawback: your inventory needs to be fully fetched for “nostrip” to work since it examines the item’s name (or the name of the folder it’s in) and until the viewer has fetched your inventory it does not know either the item’s name or even which folder it belongs to. The easiest workaround would be to place everything “nostrip” you wear inside of a hidden folder (folder that starts with dot) under your #RLV root since the viewer will always fetch that folder at login.

Some practical examples:

• Clothing layer item (ie tattoo)
  • If it’s modify: just append the name with “nostrip”, ie: Favourite Tattoo (nostrip)
  • If it’s no modify: create a .(nostrip) folder and put the item under that
• Attachment
  • If it’s modify: just append the name with “nostrip”, example: ZHAO II (nostrip)
  • If it’s no modify: create a .(nostrip) folder and put the item under that, OR if the item is already inside of a folder that specifies an attachment point then just append “nostrip”, ie: .(spine) nostrip
• Folder
  • Simply append “nostrip” to the folder’s name to make all items that belong to that folder “nostrip”
  • Please note that “nostrip” on a folder does *not* apply to any other folders it may contain (aka nested folder) with the exception of folders that merely specify an attach point