Henri Beauchamp

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

Here is my take on this matter.

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.