Cerise Sorbet

There is a start on the wiki here, but how to present more details like how the bones move will take some thinking. Unfortunately it's not as straightforward as "Torso Muscles moves these bones along this range", instead different bones are adjusted depending on how far you've moved the slider. The ID numbers in the left column are at least enough to find the values in the right section of avatar_lad.xml. The entries in there that have a list of <driven> tags will in turn get you to the subranges.

Kwakkelde Kwak wrote: Sassy Romano wrote: Right, now search for "mesh shirt" and see what you get. You'll get anything with "shirt" and anything with "mesh". Search is so utterly crap that it's next to meaningless. You can search "mesh AND shirt". (no quotation marks) You could do that, but it doen't do anything. You always get AND by default and there is no OR search. Try a search on mesh shirt, shirt mesh, then mesh AND shirt. Exact same result count. The only boolean operator keyword that does anything is NOT.

What you describe seems to just be an email exchange between a prim and your Mac's email. That doesn't seem to be an SL security problem at all. The Applescript you plugged into Mail.app is a bit much if it passes along any old shell command as legit, but you're deliberately bypassing your own security with that.

People make what they think they can sell. The buff bodies are easier. The status quo should change soon enough, once fitted mesh viewers are out of development and in wider release. =ASR= avatars could add bulk since least year, so the proof of concept is out there, it works. More avatars like that will surely follow now that this is becoming a supported feature.

Paratrex wrote: LL cannot just simply be ordered to hand over someone's chat logs. You must not be from the U.S. So my point again is the NSA can just intercept without LL even knowing it. My second point is privacy. Do you like privacy in the shower, in your bedroom? I bet you do. Actually, they can, court orders are frequently sealed. And, an order isn't strictly necessary, a simple request would do. You signed up for that when you joined SL. For example, you can look at an old copy of the ToS from 2005. This kind of thing has been in there all along. Linden can (and you authorize Linden to) disclose any information about you to private entities, law enforcement agencies or government officials, as Linden, in its sole discretion, believe necessary or appropriate to investigate or resolve possible problems or inquiries, or as otherwise required by law. What did you think that meant? =D

Yeah, that's pretty silly too, but hey, if they get to play in SL and get paid for it, more power to them.

Actually it's silly, since if people really wanted to encrypt SL chat, they already can on the existing system. Remember when the Emerald viewer had OTR?

Paratrex wrote: I understand that. I'm not talking about handing over logs. Here NSA , here is all our members chat logs. Have fun going through them all. Wouldn't it be easier for them to target one suspicious person hence snooping in between you and LL's servers? Hence the whole XMPP discussion. What is grep? It's not like it's hard to find one person's conversations in those logs, especially when you have some of the world's fastest computers at your disposal. Think about it, LL does this every day to investigate abuse reports.

Paratrex wrote: Yes my exact point with the first post. I don't care if LL reads it. I care if the NSA reads it. The NSA would reside in between you and LL's server would it not? It would not. If a govt. agency ordered LL to hand over the logs, that would be the messages that were already forwarded to their chat servers, already in plaintext.

The chat would still be plaintext to LL, so nothing would change regarding their ability to log or read messages. TLS is only to keep people in between you and the server operator from snooping in.

The TLS encrypts the communications on the wire, but it is cleartext on the chat server. Basically it works like https on the web.

I just bought a copy of the RP-017 Power Yoga AO off the marketplace and it does have a problem. Two of the hover animations are missing from the HUD inventory: D4278-Hover.N and D4279-Hover.N It takes about a day for the Oracul redelivery system to get the transaction history for new purchases, but you (and I too, it seems!) can try going to http://maps.secondlife.com/secondlife/Kuso/230/230/251 tomorrow, and try the redelivery or update from the kiosks there. If we are lucky, that will deliver a different copy without the problem. If that does not work, an IM to daiz papp will be the next step. English is a very foreign language for this creator, so a short message with just the facts - the name of the AO, names of the missing animations, that you would like a fixed version - would be best.

Negative channels are fine for llDialog and llTextBox. That's the only normal case where avatars can use negative channels. (Some TPVs can even send to negative channels from the regular chat bar; they do this by generating fake llDialog responses.)

OK, Sky Miles, so you are looking at prim or mesh heads. The blush is just an overlay prim or face. The script only has to look at what button was pushed, and send out chat that identifies the button. A script in the head listens for that chat, then uses either llSetLinkTexture or llSetLinkPrimitiveParamsFast. I'm glossing over a bunch of details, those depend on where you are starting and where you want to go. Are you trying to add features to an existing head, or building one from scratch?

The numbers are provided by the viewers in range. The server simply echoes an average of the reports over time. I didn't make that up, in fact it is repeated right on the first page you linked to. "This is a flag used with llGetObjectDetails to get the Avatar_Rendering_Cost of an avatar, based on values reported by nearby viewers." Note that so far, a Linden is the only editor of that article. See also http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2013-09-19 for a discussion of how this works.

It may not be too useful. The simulator doesn't do rendering, so it relies totally on what viewers visiting the region report, averaging them over time. Most viewers don't report anything yet. If it finds its way into security gadgets, expect people on naughty viewers to send the server low figures for themselves, and very high ones for anyone else in the region but their pals.

Kenbro Utu wrote: Pussycat Catnap wrote: Currently, nonpayment results in a permanent account deletion - unrestorable. http://wiki.secondlife.com/wiki/Linden_Lab_Official:Delinquency_policy You have 30 days before an account is placed in delinquency. I don't believe accounts are still deleted for nonpayment, there is no mention of this in the terms. Yeah, they did away with the deletion part a few years ago. Accounts that went delinquent several years ago, before they changed the policy, would have already been wiped.

Ok, so for that first image that you used in the example, the 1% transparency hack should fix it. To get rid of the gray and make the shadow all black, one quick fix is to make your alpha channel, then simply go back and paint over the shadow area with black.

In all likelihodd your texture is fine. The rounded edges show that you are getting an alpha channel, and it really does look like you are dealing with the viewer's automatic alpha mask mode. In this image, I am using the exact same texture on the exact same prim. On the left, I've forced alpha blending mode, and on the right I've forced alpha masking. Note that it looks exactly like what you're getting, even though the texture itself has a translucent shadow.

Do try the 1% thing, the alternative is to add more transparency to the image elsewhere to get it above the automatic alpha-test threshold. Plan B, if the drop shadow is always going to be there, is put that alone on a separate face behind the main tile.

It could really be there, you may be running into the viewer's automatic alpha mode switching. On the inworld editor, see what happens if you set the transparency for that face to 1%. Those look like tiles, sure you really want alpha on those in the first place? Alpha floors and walls tend to lead straight into the land of glitches.

It turned into a horrible mess over the years, but the general idea is -- Avatar components are supposed to be "system" wearables, like shapes/skins/eyes/tattoos, all the parts you might need to make a naked legacy avatar. Avatar accessories are generally attachments that don't fit in other sections like clothing, weapons, etc. Lots find it weird that hair is here instead of in components, but these categories are nearly as old as SL and prim hair wasn't always an "essential". Avatar appearance is a relic. It used to have avatar components and complete avatars underneath, now it is a dumping ground for things that really belong in other categories. It really ought to be blocked as a place to put new stuff.

There is an old OpenGL compatibility layer built into Windows' generic fallback graphic driver, but it is not what SL uses. The generic Microsoft implementaion only supports OpenGL 1.4 or so. The GPUs supported by SL have drivers supplied by their manufacturers, and these run OpenGL and DirectX as parallel APIs, not layered.

Darien Caldwell wrote: I dont' know what makes you think bots are the biggest source of "group chat overload". I don't know either, because you made that up, it's not what I wrote. You even quoted it, "one of the biggest causes", not the biggest cause, and you still were unable to read it the second time. Nothing could be farther from the truth. Impressive sounding statement, except that it actually is true, There really are lots of extremely large groups for stores and clubs that had been using bots to send out out multiple identical group notices a day, often followed by group chat messages repeating them. The first three such groups that popped into my recollection in the last minute have 11000, 96000 and 11700 members each today, and that's the tip of the iceberg. This automated repeat group notice activity had been so common that it became a standard bot feature, MetaBOLT provides the GIM plugin for this purpose, with equivalents provided by SmartBots, PikkuBot, and various smaller ones. Group messages all share a single system. and as such, this notice activity had been robbing server capacity from all groups, even if you personally haven't joined the spammy ones, and even if you were unaware that they exist. They may be the biggest source of fraud and annoyance. But compared to all the real users of group chat that actually put 99% of the load on the group system, they are a drop in the bucket. Those really huge groups generally don't have chat enabled, but most groups with active chat have a fraction of the membership of these. Chats also don't reach out to the mail queue like invitations and notices. While there certainly is hit and run group chat spam, SL already had those cases covered as community standards and ToS violations.

Really, "a message is a message"is a good enough working defintion. Behind the viewer interface, the differences aren't so big. An instant message, group invitation, inventory offer are really all the same thing. The viewer just treats them differently depending on flags set on the IM. Group chat and group notices are also related to each other, though group notices are heavier because of the offline option.