Release: RLVa-0.2.2b (updated)
Barring bug fixes that really can’t wait this is most likely the last “pre-release” version of RLVa, with the next one finally getting its shiny 1.0
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
Good job there getting the updates out so quickly.
Nice job on the changelog file. I’ve done a couple patches and many ebuilds, but my changelog skills are sorely lacking and was wondering what program you used for the changelogs?
My take is that her programm is “Kitty Paws”
.
Am I right, Kitty? *pokes*
@Techwolf Lupindo
Err.. uhm.. I use a very highly specialized proggie called “Notepad” :p.
I’ve tried a whole lot of things over time really, and in the end I’ve found that the only one I actually have the long-term discipline for is having a text file to scribble notes in right along with the source files. As long as you get in the habit of writing up *something* in the file before actually doing the change it works out well.
All in all I’m not sure if the changelog is that interesting to anyone but me anyway
.
@Satomi Ahn
“Kitty paws” is what I use to type with, silly! :p
*wonders why her comments have the creepy looking cartoon on the right side*
Hi I want to use this version of rlva with gemini viewer, your full patch command line works with it but its not doing nething
is there a specific sl i need to use with the full patch? can u please help?
*waves*
I’m not really sure what you’re trying to do? *confuzzled*
Skills apparantly applied the very first draft of RLVa to her Gemini viewer; hopefully her next release will have fully functional RLV support one way or another.
If you’re trying to unapply the patch she applied and then reapply the last one posted here, that’s likely not going to result in anything good due to leftovers.
Best advice would be to wait for her to release a new RC of her viewer, it will sort everything out hopefully.
*pokes*
Have you already seen this, Kitty, btw: http://crystalserver.freehostia.com/slattachments.php ?
This is a simple viewer mod for having lots of attachment points. Every attach point is tripled: chest, chest 1, chest 2,… and there are three whole new names: script, neck (attached to neck joint!), and tail.
Would it require modifications to make it work with RLV commands like @detach or @getattach?
@Satomi Ahn
If I had to guess I’d say that it should just work as-is for the most part…
The only thing that’s guaranteed to fail is the “resolve attachment point ‘hint’ from an inventory object’s name” function because it’s – purposefully – strict on what kind of input it will accept (more specifically it would stumble over the () in “Chest (2)”).
It’s easily remedied though since it just requires changes to 2 functions, but meanwhile things like @attach:folder=force wouldn’t work for those new attachment points (others like @getattach=channel and @detach:chest (2)=force for instance should be fine on their own though).
I’ll look into trying to make the matching a bit looser and still prevent false positives (which is the main reason it’s so strict about what it’ll accept as attachment point ‘hint’).
I assume you’re volunteering to be a guinea pig? :p
(Also there’s likely some Linden code that’s guaranteed to fail since some function make the assumption that HUD attachments will always belong to a specific attachment point ID range)