RLVa

I *finally* got around to writing this blog post (and uploading the source for RLVa-1.0.1) .

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