RLVa

*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

*waves*

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

I promised I’d write about some RLVa features that never did made it into a release :). These posts (there will probably be three of them) aren’t an announcement that they will get added but rather to describe the original intent or idea behind the feature, what prevented it from being included and to sollicit feedback on whether anyone actually wants it/them first of all, and how they’d like them to work if that’s the case.

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

Every now and then I’ll spot a question or problem along the lines 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.

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.