Cerise Sorbet

Some limitations with that approach -- Child movement is planar, regardless of the actual face shape. It will be good to add a test for llDetectedTouchFace because touches on other faces will move the child to to the corresponding point on face 0. The taper, twist and shear must be 0 or tracking will be distorted.

The AO part is only cosmetic. The important thing is that you're actually sitting (which as you noted in your OP, does work).

steph Arnott wrote: Examples or better versions can be submitted to the wiki thru one of the members that have edit writes. There are a few here in the forum. I have found errors as well, but to be fair on the wiki mentors keeping it all Upton date and bug free is not easy with other commitments. BTW i did not get the wrong end of the stick, which is why i said submit a better version. Anyone with a Second Life account can edit the wiki. The "Linden Lab Official" pages and a few others are restricted to LL, but everything else is open for the whole community to tweak.

In Radegast, World>Sit on Ground will do all you need. (That terminology is kind of historic, it will work even if you are on a prim surface.) If you would rather look like you are standing, wear an AO and put a stand animation in the ground sit slot.

default{ touch_start(integer total_number) { llSetLinkPrimitiveParams(3, [PRIM_POSITION, (llDetectedTouchPos(0) - llGetRootPosition()) / llGetRootRotation() ]); }} If this example is in the root prim of an object, then touching any surface on the linkset would move prim 3 to the position you touch. If you put the same script in a child prim, then link 3 would only be moved to touched spots on that prim. You can use llDetectedLinkNumber to choose what touches to act on, if you would rather have the script in the root prim,

Wait, so you think it is abusive to not charge for demo items? You're really barking up the wrong tree.

Demos at that price point are not abusive. Demo items are really important tools to allow try before you buy, especially for wearable items. The marketplace site simply doesn't support listing demo items in a sane way. Only LL can solve this by adding support for a demo flag, making it possible to filter searches based on that, and then insisting on its use. If you think land pricing is scammy, flag it. However, land has an excepton in the marketplace guidelines; unlike for other categories, non-item listings are allowed there.

mtwtfss71 wrote: Often times the problem is with the weight painting of the clothing. If that isn't properly done, any alpha will likely show through on certain movements of your avatar. Until we get the deformer, there are always going to be issues like this. I include the alpha and alpha textures full perm with all of my mesh and I test all of the sizes but I know there will never be a perfect fit for all customers. It also surprises me how many customers don't try the demo first. Deformer does not fix this issue, it can even make clipping issues more obvious because you can't simply take a little meat off the avatar to hide it.

The avatar in your second picture was made that way before it was uploaded to SL. It uses different materials for different sections, and those become prim faces in the SL editor. Each face can use its own textures, tinting, alpha, etc. The HUD there only has to tweak the transparency level on those faces. If the avatar in the first picture wasn't made that way, you would need to download the skin texture, make transparent holes in it yourself with an image editor, then put the modded skin on the mesh in place of the normal one. If that first avatar WAS made with more than one face, you can still change them in the SL editor, using "Select face" and the transparency setting in the texture tab. As long as the mesh is modifiable, that is. A HUD to do that is just a convenience.

TheonlyJohnny wrote: So I wouldn't get banned for selling them in my shop then? You could get banned, but it's not a sure thing either way. It's up to the people who made those avatars if they want to have them taken down. Some act on it, some don't. It's up to LL to decide if an account has racked up enough takedowns to warrant a ban. If they have a formula to decide how much infringement is too much, they have been good at keeping that a secret.

Yes, the account stays active for a short while, until the next billing cycle. See here in the knowledge base if you have changed your mind; if you get in a ticket quickly enough, they may be able to stop the clock.

They call these tattoos to make them sound edgy, but they are disposable stickers that fall off within a week or two. They are developing these as alternatives to wearables like smart watches and headsets, on the notion that people who think the other devices look dorky, might think these Borg stickers look cool.

Go ahead and keep the old avatar alive, a note that you were in suspended animation for several years and have to do the noob thing all over again will cover it. I've a few SL friends who did this and it all worked out fine. Remember too that really old accounts get a little weekly stipend, even if they were basic, but only if they log in at least once a week.

You may get smoother results if it's physical. llTargetOmega switches to server-side motion in that case. llSetAngularVelocity can also be good for something like this that receives frequent changes, the slowdown is very gradual and virtually invisible with regular refreshes. Set it phantom, use llSetStatus to turn off X and Y movement, and you'll need a bit llMoveToTarget to nudge it into its intended place.

Hi, you generally don't need any kind of special script for this any more. In the prim editor's features tab, you can set the child prims' physics type to none. If you do have a need to switch this on and off, you can use PRIM_PHYSICS_SHAPE_TYPE in llSetPrimitiveParamsFast. All you need are the link numbers, not UUIDs. Mesh objects don't have visible UUIDs like the sculpted prims did. If you need to identify them on the fly, you can tag them with a special name or description, then find them with llGetLinkPrimitiveParams and fetch the PRIM_NAME or PRIM_DESC properties.

There was talk a few months ago, that it would be possible to make a viewer with SSA that did not have mesh support too. It was only talk, and you can go ahead and assume that everybopdy can see mesh now, if they can see much at all.

Innula Zenovka wrote: Just to clarify about the "shared viewing experience," that doesn't mean that things have to look the same for everyone -- as you rightly say, that's never been the case, even before TPVs were in any sort of wide use. What that means, as I understand it, is that TPVs can't (with a couple of agreed exceptions that were grandfathered in) use visual effects that rely on technology that isn't there in the official viewer. The classic example are the old illegal attachment points that Emerald used to use -- they looked good to people using TPVs that could see the extra points but people not using such viewers saw the attachments floating round in space rather than attached to the avatar. Those were really fallout from another viewer that was stopped earlier. One person worked out a scheme that hosted sort of a competing virtual world on top of Second Life's infrastructure, using a private asset store accessed by a special viewer. This viewer was denied a TPV listing for the shared experience reason, then that policy was made formal about a year later.

It's allowed, the feature actually originated in the official viewer. Third parties just added names to make the markers easier to tell apart. They can't actually track your camera, what they really see are the information about where your avatar's eyes are supposed to be pointing. The information isn't private, your viewer broadcasts those. Many third party viewers have a "private look at" feature that will stop your viewer from sending them. If you use the official viewer, you have to do a little bit fancier work to tailor them, but you still can; see Show Look At on the SL wiki for details.

Yes they do have a little help for that! The page for that is https://marketplace.secondlife.com/orders - you can get there by picking "my account" from "My Marketplace" at the top of any MP page. Order history will be one of the options over on the left of the page.

Knutz Scorpio wrote: The sailboat I had fun with but got tired of the wind just abruptly changing and having to wiggle around to find it again, is that normal for sailing in SL? It kind of is. LL made some changes a few months ago so that the system wind would change around less often, but those stalls can still be maddening. For what it's worth, that happens some days with the real thing too. That boat does have an option to use a built-in "HUD wind" instead of the "real" region weather, if you don't want to deal with the variability. There is always the motor if you don't feel like messing with it at all (but it goes super slow on the motor).

Looks like the rail hand car is still available too. Teleport to http://maps.secondlife.com/secondlife/Saminekim/41/75/51 ... landing point sticks you on a hill with a vendor that gives out the plane, so go south and west down the hill, to where you see a shed with some yellow trucks. The hand car is in the shed.

"LinkFailedNothingLinkable" usually means that you are trying to link things together while you are wearing them. We can't do it way, objects have to be rezzed out on the world and not attached before lnk or unlink can work.

there should be a dispenser for that dune buggy at the premium racer's gulch sim.

Xiija wrote: (there may be the possibility that depricated functions could get removed, but i have never seen this happen?) personally, i have used llSound() for years and no problems llSound is probably safe, it was "replaced" in ancient times. Some functions have been outright killed. There has been no viewer support for llCollisionSprite for years, The server doesn't generate particle cloud information any more, so llCloud is dead. LL intends to kill off XML-RPC, but it has got a long reprieve because the remaining Xstreet magic boxes still rely on it.

If it follows the account, one possibility is that a gesture is using M as its shortcut key. So, try removing all active gestures, and see if that makes a difference. (The standard viewer won't create gestures with plain letter keys as shortcuts, but it can play ones built that way from other viewers.) There is also a preferences toggle to go between letter keys starting chat or moving the avatar, but I don't think that's your trouble since it's not affecting all accounts. There is a bug in LSL that can cause attachments that take controls to break clicking in mouselook, so you can also try removing all your attachments to see if that problem goes away. If gestures or attachments seem to be behind the problem, you can put them back on one at a time, then try out mouselook and clicking in it, to identify the culprit(s).