RLVa

*waves*

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

*waves*

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 )

(Thankies to Satomi for originally suggesting the feature and for putting up with me telling her that “I’m going to have to kill off composite folders because…” every other version :p… And while we’re on the subject: “I’m likely going to have to remove composites for 2.0 because they don’t play nice with item links” *ducks quickly*)

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!

*waves*

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

I’ve had to deal with some medical problems for the past week and a half and I probably have some surgery to look forward to as well in the near future so my schedule has changed a bit since the last post .

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/

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

*waves*

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

There’s been some buzz about the extra attachment points that are now included in Emerald by default, particularly in how they relate to “force stripping”.

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)

I should be in bed already so this is going to be short .

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

*waves*

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