Henri Beauchamp
-
Posts
1,180 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
The new Bento project viewer (v5.0.0.313150) emits the following warnings about the new shape visual parameters:
2016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 12016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 22016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 42016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 102016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 112016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 142016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 152016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 182016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 202016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 242016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 252016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 272016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 352016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 1552016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 1852016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 5052016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 5062016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 5172016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6292016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6502016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6532016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6562016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6592016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6632016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6652016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7582016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7642016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7652016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7962016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7992016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 1105
Note that the warning about visual param 1105 (a physics param, so it's not quite as important as the rest) exists in all viewers, but all the others are new, and do impact the newly introduced "sliders" parameters...
-
I just backported the latest changes to the Bento skeleton into my viewer and I'm getting these warnings about the new visual parameters:
WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 1WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 2WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 4WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 10WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 11WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 14WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 15WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 18WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 20WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 24WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 25WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 27WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 35WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 155WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 185WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 505WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 506WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 517WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 629WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 650WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 653WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 656WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 659WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 663WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 665WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 758WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 764WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 765WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 796WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 799WARNING: LLWearable::createVisualParams: Could not link driven params for wearable Test shape id: 1105
Note sure if it is a critical issue or not (the warning about visual parameter 1105 has been there like forever in all viewers)... -
Vir Linden wrote:Henri, re: avatar_skeleton_spine_joints.xml:Any extra avatar_skeleton or avatar_lad files are for use during development - I had added that one to make it easier to test with and without spine joints when trying to fix an associated rendering bug. We'll remove the extra files before release - in the meantime, they won't affect the behavior of the viewer unless they are copied in place of the standard files.
OK, understood. There's however still the issue with the missing mFaceEarLeft and mFaceEarRight joints/bones which the Bento viewer is complaining about for "Alt Left/Right Ear"...
-
Vir Linden wrote:The Bento project viewer is now updated with the new skeleton, and back-end enforcement on most regions of Aditi is being updated to match. As before, you can upload any bones in the BentoExperimental1 region.
What is the use of character/avatar_skeleton_spine_joints.xml ? I cannot find any reference to it in the bento-box viewer code neither in any of the character/*.xml files, and no occurrence either in the viewer binary ('strings do-not-directly-run-secondlife-bin | grep spine_joints' doesn't show any occurrence in v5.0.0.311861) ?
There is also an issue with:
2016-03-07T19:43:40Z INFO: LLVOAvatar::loadSkeletonNode: attachment pt Alt Left Ear using mPelvis as default parent2016-03-07T19:43:40Z INFO: LLVOAvatar::loadSkeletonNode: attachment pt Alt Right Ear using mPelvis as default parent
Which is more explicitly logged, in my backport of bento-box to the Cool VL Viewer, as:
2016-03-07T19:14:33Z WARNING: LLVOAvatar::loadSkeletonNode: Avatar: - No parent joint by name mFaceEarLeft found for attachment point Alt Left Ear, using pelvis as the default parent.2016-03-07T19:14:33Z WARNING: LLVOAvatar::loadSkeletonNode: Avatar: - No parent joint by name mFaceEarRight found for attachment point Alt Right Ear, using pelvis as the default parent.
And when looking at avatar_skeleton_spine_joints.xml mFaceEarLeft and mFaceEarRight joints do exist, unlike in avatar_lad.xml...
Missing code in the viewer ?... Or missing joints in avatar_lad.xml ?
-
1
-
-
Alwin Alcott wrote:if you have access to info from members of SL, owned by LL, its totally normal and legal to ask you who you are.That you don't comply is enough reason to have doubts.
Do not speak about things you don't have the single clue about in the first place.
It's not just about "knowing who I am" (they already know, by the way, since I've got payment info handed out to them), but LL also requires in their Contribution Agreement form the snail mail address and phone number: the latter two pieces of info are excessive for the purpose (they only need my RL name, which, again they already have, and my signature, which I'm ready to provide).
Mind you US laws are not universal, and each country got their own law, that are no less valid than US laws. In my country (and in European countries, because there's also a law in the UE about this subject), the privacy of the citizen is guaranteed against the abusive prying eyes of private companies and interest groups. According to these laws, LL's requirements for a Contribution Agreement are simply illegal (because excessive for the purpose) and I'm totally well founded to refuse providing them with the info they illegally require from me, French citizen.
Now, my remark about the FUD you spread, was not even about the CA: there is no need for a CA in the first place for any TPV developer, because while the listing into LL's TPV directory is conditionned to the signature of a CA, the listing in that TPV directory is NOT A REQUIREMENT (NEITHER A GUARANTEE FROM LL) for a third party viewer to be considered as TPV-Policy compliant (please, DO READ the TPV Policy, paragraph 6: "Unlike the other sections of this Policy, participation in the Viewer Directory is currently not a requirement for connecting to Second Life. "). Again, the Cool VL Viewer is, and has always been, fully TPV-compliant; had it been otherwise, it would have long been blocked by LL (and the Cool VL Viewer has been around for 9+ years: it's the oldest TPV still actively developed) !
So, I don't have "to comply", because the signature of a CA is only a voluntary act from the signee, not a requirement from LL. The fact I didn't sign it simply means that LL refuses to include any code I write in their own viewer (too bad for them: their loss, not mine) and that they won't list my viewer into their optional directory (like if I care !... I made the Cool VL Viewer for myself and I'm only sharing it for like-minded people to enjoy it).
Also, unlike what you suggest here, I have NO ACCESS WHATSOEVER to "info from members of SL" (again you are spreading FUD here !): if you are not convinced, examine the Cool VL Viewer sources: they are Open for anyone to check. I don't even make the viewer login page point to a custom web server (like Firestorm does), so I have no way whatsoever to know who and when some SL user is connecting with the Cool VL Viewer.
-
Alwin Alcott wrote:if a software supplier so openly refuses to comply to the 3rd party policy you shouldn't put questions about it on the forum of LL., and not use it for SL anyway...
Please, stop spreading FUD !
Like I wrote on the Cool VL Viewer website:
The Cool VL Viewer is itself TPV-policy compliant (and for people wondering why it is not listed in LL's TPV directory, it's simply because I don't want to provide private data to LL about myself, data which is illegal to require for such a purpose in my country. Being listed in the directory is in no way a requirement for a viewer to be considered TPV-policy compliant anyway: see the paragraph 6 of the TPV policy).
-
Vir Linden wrote:Re: using "Right" vs "R" and so on in attachment point names: unfortunately the older attachment points aren't named consistently either, so we have "Right Ear", "Right Pec", but "R Uppper Arm", "R Forearm", so you could legitimately make a case for naming the new attachment points either way. Since the long form, with "Right" and "Left" fully spelled out, is more common in the existing attachment points, as well as in other existing bones, I think it may make more sense to standardize on that.
However, there is one "standard"/"rule": all legacy "long named joints" (joint names with three words or more) got Left/Right abbreviated to L/R and Left/right is only fully spelled for two-words joint names... It does matter for the UI (especially v1 UI, with the pie menu slices which offer a limited space for each joint name)...
-
I just released the Cool VL Viewer v1.26.17.3 (i.e. a new release in the experimental branch of the viewer), with full support for the Bento-skeleton.
There's one thing I'd like LL to change in their current implementation: the attachment points names for the new joints such as "Left Ring Finger" and "Right Ring Finger" would be better named as "L Ring Finger" and "R Ring Finger" (and "Alt Left/Right XXX" as "Alt L/R XXX"), so to match the naming convention (and shorter names) already used for "L/R Upper Arm", "L/R Lower Leg", etc...
This may seem a minor issue, since any viewer developer may change these names in their viewer UI by editing the strings.xml file, but for Restrained Love, it will set the standards for "official" joint names to be used in its commands (which don't rely on the language/translations used in the UI)...
-
Like any other viewer, the Cool VL Viewer only allows to export as an XML file objects that you created (as per SL's TPV Policy) or are full-perm (OpenSim (*)).
If you created the object yourself, then you are obviously free to export and re-import it on any grid (AFAIK, no grid TOS restricts anyone to reuse their own creations in other grids).
However, if you were given just the XML file from the object's owner, then you must ask to this person whether or not they are the creator for it and allow you to import their work on SL (since it would make you the (apparent) "creator" of that object in SL, they might reply "no, sorry"), or if they just exported a "full perm" object (in which case, the license that goes with this object must first be checked and/or the permission asked to its actual creator).
(*) The Cool VL Viewer also abides the new "export" permission for OpenSim grids implementing it.
-
LaskyaClaren wrote:
I have no problems whatsoever with a segregated area like the teen grid. In fact, that was a pretty vibrant, if very small, community. Intelligently managed, it could serve as a way of nurturing future adult SLers by introducing them to the platform.I didn't have any problem with such an area either, but LL so far preferred to segregate adults rather than teens... I don't want to see this harmful (for SL and its residents) trend amplified by a new CEO who would suddenly think that there should be more teens on SL and make "more room" for them, to the expense of adult activities.
A very large number of residents would like to experience a grown-up environment that also doesn't mean inadvertently happening upon really explicit or ultra-violent stuff. There is a reason why, despite the slow expansion of Adult areas, "Moderate" is still by far and away the most popular rating. And even ignoring the possible presence of teens, I've no doubt that there are adults who prefer "General" even to "Moderate." Why would we not also cater to their preferences? .../... Please understand, however, that there are a great many of us -- perhaps a majority -- who have no problems with, and may even seek out, nudity or mild violence (for instance, a basic combat or zombie sim) but don't want to be unwillingly exposed to Dolcet or "forced sex" toys.You won't stumble inadvertently into such areas, because they are duly flagged with explicit warnings and disclaimers at landing points: if you stumbled upon them (and didn't see those big red warnings), that's either because you were seeking for them, or some of them are now allowing TPs away from the landing point as a result of being located in an Adult sim (something that won't have happened in the old SL, with only PG and Mature sims).
Given that you produce adult products, I entirely understand why you don't like to have access to your content restricted by a ratings system.Today, my worries are not at all with the products I sell (and yes, my SL incomes got divided by 8 between 2007 and 2014... but the Adult segregation is not the only reason, by far), but with the fun I can get, as a passionate and very involved resident in SL (how many residents are capable of taking on themselves to fork LL's viewer and maintain their own branch for 7 years and still counting so that they can still enjoy SL instead of giving up on it because of LL's crippled viewer ?... Well, at least one such resident exists in SL). If LL is going to spoil my fun, then I'll be voting with my feet real soon !
-
LaskyaClaren wrote:
I respectfully disagree. I think we need younger people here, and more of them: they are the future. It is possible, using rating systems and, possibly, by putting back into force a more stringent age verification regime, to have both teens and adults here.The former adult checking system (with Aristotle) was making it *impossible* for most EU residents to get verified (because despite their claim, Aristotle had no access whatsoever to privacy sensitive databases in EU: unlike in the US, privacy DOES matter here !). Putting it back (or something similar) in force would be extremely dangerous since it means many, many, many adult residents would suddenly loose access to Adult sims (not to mention that any US teen could perfectly (and many probably did) give the details of their parents and get their avatar "verified" as a result) !!!
You simply have to accept that, while a company such as LL *must* try and restrict access to adults for adult stuff, there is no way to ensure that a teen will never get access to things they should never see (this is not only true in SL, but anywhere on Internet).
I simply don't want for LL to make it feel like teens are welcome to do what Ebbe's son did, because this is putting both the teens and the adults into danger !!!
I also disagree with the notion of getting rid of the "adult" classification. This is sort of what I meant in the comment above about a too narrow view of the experience of SL: there is, or certainly should be, a difference between an experience of SL that falls under the "Adult" rating, and one that is "Moderate." There is an enormous difference between wandering around a sim and running across, for instance, a nude beach or artwork featuring nudity, and tripping over a Dolcet or Gor sim. And I'm pretty sure that I speak for a majority in that regard.That's what PG sims (now "General") are for !!! PG sims are like the streets in real-life: you normally (i.e. as long as no one violates the Law) don't see violent or sexual stuff in RL when you walk down a street... RL streets are "PG" (i.e. safe for teens and even children to roam in).
The former "Mature" (now "Moderate") rating did correspond to what is now flagged "Adult". There's no need at all for an "Adult" rating: that one was invented to segregate "adult stuff" into the newly created Zindra, but if you do roam SL enough in search for "adult stuff", you'll find it in "Moderate" sims as well, and since teens are limited to "PG" sims it's not a problem either.
To be honest, I'd like to see the "violence" part of the Adult rating focussed upon more than the sex side: I'm much more personally offended and disturbed by animations involving snuff and dismemberment than I am ones that represent (please note my use of this word!) consensual sexuality."Violence" is part of what I called "Immoral roleplay" in my post: I could have written "roleplay that is legal (even if disturbing to many) because it's pure fantasy in SL, but that would be illegal if the depicted actions were to be acted out in real life"...
-
I can only second Innula's worries and encourage Ebbe to reply to them.
After reading Ebbe's first pieces of nice prose, I can only worry about how "adult stuff" (yes, do read it as "virtual sex", "weird, exotic and twisted kinks" and "immoral role-play" between avatars pertaining to consenting adults) will be dealt with in the future.
I especially dread the day when teens would be allowed to interact with adults in SL. As an adult, I don't want to risk role-playing with a teen thinking they are an adult.
I also hated how LL segregated us, "adult roleplayers", into Zindra, while what would have been the right thing to do would have been to create a PG continent for educational and teen use instead and let the rest of the gird as it was (there was especially no need to create an "Adult" rating: "Mature" was explicit enough and appropriate).
I'd urge LL's new CEO not to make a mistake: "adult stuff" drives a very large part of the SL economy. It must be acknowledged and welcomed by LL, instead of being seen as a "dirty little secret" that should be hidden behind a pseudo Disney Land-like front window. -
Czari Zenovka wrote:BTW, I thought we couldn't see anyone else's jiras anymore. Did LL change that back and not tell us?
It depends on the settings Lindens chose for each particular type of JIRA issue. The SUN (Sunshine) issue, like some other project issues are open for everyone to see/vote/watch, and for TPV developers to create new issues and comment about existing ones.
-
I found a very bad impact of server-side baking, that I described in this JIRA:
https://jira.secondlife.com/browse/SUN-38
If you are worried about this issue, please both vote and watch it (note that Lindens tend to judge about the popularity of JIRA issues based on the watchers rather than on the voters numbers).
-
For anyone who cares, today's Cool VL Viewer releases implement pure viewer-side Classic Clouds (meaning that when logged in a sim or on a grid where Classic Clouds update messages are missing, the viewer auto-generates the equivalent data to still be able to render the clouds).
Henri (revolted against and resisisting stupid changes in SL since 2007). -
Perrie Juran wrote:Ansariel Hiller wrote:Perrie Juran wrote:Qie Niangao wrote:I think perhaps you should read Henri's comment again. He's basically saying that Niran is full of beans.
What puzzles me is how Henri could have tested to see if RLV worked if scripts were not enabled on test Grid.Did they finally get enabled? The last I had read was the TPV's requested this.Scripts are now enabled on some test regions, since one or two days...Henri's comment was posted on the 15th (yesterday) so then it is possible he has tested it.Stop spreading FUD, folks:
1.- I said nothing about Niran and his viewer, ever !
2.- You don't need scripts to test the compatibility between RLV and the server-side baking code and, more exactly, the refactoring of the code that is actually common to both baking methods, the part dealing with RLV features not even being the one that deals with actual baking, but simply with removal/wearing of clothing items: if RLV works fine in non server-side baking regions, it will also work fine in server-side baking ones, because the RLV code is called way before baking does happen (it is only called when you (or scripts) try and wear or remove clothing items: it's all viewer-side stuff: the server doesn't care or even know whether your viewer uses RLV or not, it just replies to the viewer request to rebake whatever the viewer decided your avatar should be wearing). My guess is that RLVa is impacted because it is written differently than the genuine RLV and had many tests spread all over the code (especially the COF code, COF that I didn't use and reimplemented in a straight, simple, no-brainer way in just under 4 hours) that has been refactored (when my RLV implementation only called the RLV code in two places in the code that got refactored): doing an automatic, "en bloc" merging of LL's code changes (I merged it all by hand, file after file, line after line, in under two weeks during part of my free time) probably caused many rejects in RLVa viewers but server side baking itself is for nothing at all in this mess.
3.- Even in a no scripts region, you can get attached items scripts to work (just fly 50+ meters above the ground and/or use scripts which use a llTakeControls()), and that's all you need to test RLV scripts.
-
And after removing the classic clouds support from their viewer, LL is now going to remove them from their server, meaning even the residents using viewers that are able to render them will soon not see them any more !
The Cool VL Viewer (in which you can even adjust the altitude of the classic clouds: something that would be easy to implement in other viewers as well) and Singularity for the actively maintained viewers, plus all “deprecated” viewers, at least up to v2.7 *cannot* render them in RC Magnum already.
I filed a bug report (https://jira.secondlife.com/browse/BUG-1456) but Maestro Linden closed it as “expected behavior”. I’d suggest that anyone interested in classic clouds (which I find way prettier and realistic than Windlight clouds) also file BUG reports on the JIRA to let LL know that we still want classic clouds in our SL experience !
-
@Oskar
As described in my bug report, SVC-8124, while indeed being a RC Magnum bug, does affect all other neighbouring regions, since as soon as your viewer connects to a RC Magnum region (neighbouring regions included), it gets spammed with ParcelOverlay messages.
-
Alas, while the "allow_return_encroaching_object" sim parameter is indeed set to TRUE and allows to return encroaching objects which have not been rezzed with the land group, the "allow_return_encroaching_estate_object" parameter is still FALSE, meaning that if the land where the encroaching object got an open group and the one rezzing the object did use that group, or if your indelicate neighbour encroaches your parcel with their builds, you will not be able to return the encroaching objects...
Please, could you set allow_return_encroaching_estate_object to TRUE on mainland ?...
-
-
Tristizia Demonista wrote:Is there a chance that Cool will also at some time support Multiple Attachment on the same point ?
It already does !!!
It was the first v1 viewer to support v2-like multiple attachments ! Like it was the first v1 viewer to support Alpha and Tattoos, item links, new search, etc... and now meshes.
Facebook
Instagram
Twitter
YouTube
Flickr
Check out the screenshots for The Cool VL Viewer
in Second Life Viewer
Posted
Now, I'm pissed off !
If only people could stop spreading FUD !!!
The reasons why I prefer keeping a few (very personal) pieces of info (such as my phone number, which I reserve to the exclusive usage of my family and friends: it's on "liste rouge" and is never listed in any public record/phone book) over seeing my viewer listed in the TPV directory are mine, and they are also totally legally founded (mind you, French (and EU) laws are more protective than US laws about privacy, and we do care a lot about privacy in "old Europe", and find US companies aggressiveness towards private data theft of foreign citizens quite disturbing and even revolting !).
For your info, my identity is also known to LL (since money exchanges have been done between LL and me). I just don't want to give away info that is excessive for the purpose (here, the purpose is a "contribution agreement", something that should really not require me to give out a red-listed phone number, especially since I won't understand a damned word of spoken English !).
This said, and citing the paragraph 6 of LL's TPV policy:
"6. The Viewer Directory and Self-Certification
We created the Viewer Directory to help promote awareness of Third-Party Viewers within the Second Life community. Unlike the other sections of this Policy, participation in the Viewer Directory is currently not a requirement for connecting to Second Life. "
and at the end of that paragraph, you can read:
"c. The Viewer Directory is a self-certification program. Linden Lab does not represent or warrant any independent testing or verification of compliance of any application listed in the Viewer Directory. We disclaim all liability associated with applications in the Viewer Directory."
Emphasis mine (since some of you just can't seem to be capable of reading and spotting the phrases that actually matter).
TPV viewers are Open Source and the beauty of Open Source is that you can check by yourself that a software is not malicious or violates any rule. In the case of the Cool VL Viewer (and its former Cool SL Viewer incarnation), the TPV Policy compliance is 100%. It's even better than most other TPVs, if not all: do you know, for example, of any other TPV which presents you with the required disclosures on first run (para 1.c of the TPV Policy) ?... Well, that feature has been implemented in my viewer only one week (!) after LL published that policy...
I'll also add that my viewer has been around since 2007: it's the oldest actively maintained TPV. If, at any point, LL had detected any non-compliance to their TPV Policy, do you really think they won't have blocked it already ?
Finally, I've seen stupid things posted in this thread about the Cool VL Viewer features: my viewer got weekly releases and features that stay top-notch and in sync with LL's viewers, including projects viewers: the experimental branch of my viewer implements Bento, for example.
Yes, it's a v1 UI viewer (the UI is based on (but also vastly expanded from) LL's v1.18 viewer), but it got all the bells and whistles of modern viewers.
Now, as for the "popularity" of my viewer, I really do not care ! I made it for myself and I'm only sharing it as a service to like-minded people. If you don't like it, then fine, please use any viewer fancying you !