Cerise Sorbet

"else if" is fine, no need to fully evaluate all those later "if" expressions in the chain that way. Until about 5 years ago, the LSL compiler would choke on fairly short "else if" chains if you were compiling under Windows, and "if ... if ..." was the workaround. This problem went away when all compiling moved to the server.

On Bluesteel, is the BUG-3291 fix meant to address the same cases as SCR-43? Sounds like a reverse statement of the same problem, at least.

Ok, then I'll put you in the "fails to understand that unsolicited advice is a social faux pas" slot.

I drop conversatins that start like this because they will invariably lead to "I'm a perfeshunal super computer genius expert" followed by a stream of hilarously incorrect technobabble. For the voice thing, even "what viewer do you use" is off in left field when the issue is biological.

The old kind can be very useful, in case you teleport to a 'G' region and there are attachment rez delays or similar issues.

Captcha solving services cost around 1 to 2 USD per 1000.

Intoxicate wrote: I agree that's a fabulous option. But OMG how have they been neglecting this for the past SIX YEARS??! It's been like that sonce the beginnning. The shirt, pants, undershirt and underpants layers are really beng used outside their intended designs when clothes try to span two different wearables like that. the problem is simply that the mask ends right there, so there will always be a slightly fuzzy edge left over from resampling. To make those combinations work together more smoothly, there would have to be extra texture panels added so that the could be overlap, but the template change is whrere it gets icky for compatibility. They could also do something hacky, like duplicate the last row or two of pixels, but that could end up adding distortion to clothes that relied on the old behavior.

The current version of this in JIRA is https://jira.secondlife.com/browse/SH-2103 The "someday/maybe" tag on there means it's reallllllly low on the list of things that needs to be updated. I suspect it might be better for compatibility if new wearables were introduced. Maybe a bodysuit wearable that could go over the undershirt/underpants layers, and a jumpsuit with the shirt/pants flare options that could go over shirts/pants. These would have upper and lower sections that avoid the old gap problem, and not disturb what came before.

I notice that a marketplace search for "preteen" only brings up two items, and neither of those actually use the word in the description or keywords. One has it in its inventory contents, the other doesn't seem to us it anywhere (maybe deleted after indexing). So, that word might be a good candidate to try removing.

It's an ugly old bug. The skin, jacket and tattoo wearables don't exhibit the bug, so you might try making your shorts up as a tattoo. If it still doesn't work right as a tattoo, double check that your textures bleed a little over the templates, so the fuzz at lower levels of detail won't make a seam.

This works if you are in a busy place that exceeds your maximum avatars setting. If the nearest avatars are not so close, then impostering won't happen. On the other hand, avatars are typically really small on screen by the time you get to the lowest LoD, so you can probably get away with a super simple token representation.

Dependng on the bug of the week, even small or infrequent changes can trigger this kind of glitch. Small changes on attachments are the traditional favorite spots to see this kind of trouble.

This has always been a problem with frequent object updates. The common workaround is to periodically force a full object update message to be sent out to the viewers. I wouldn't do this on every transition, but perhaps once every second or two to clean up after glitching. These messages are quite a bit larger than the partials sent for changes like alpha, so sending too many could compound the problem in laggy places. One of the most popular ways to force a full update is with llSetText. It's OK for the alpha to be 0.0, but you should change the text or color each time so that the update isn't optimized out. With good fortune this may be all you'll need to do.

Older viewers can't create those conference calls so easily, but they certainly can participate in them and the output is just as messy.

There is a workaround for that, but it would be nice if viewers could expose it more conveniently. Local textures actually do have UUIDs. If you apply the desired local texture to a prim of your own, you can retrieve it with llGetTexture, then paste that UUID into the car's texture prompt. The same limitations apply: only you can see them, and it's up to your viewer if it wants to remember those UUIDs between logins (standard viewer doesn't try to remember).

Gadget Portal wrote: Temp textures for non-clothing should still work though, shouldn't they? After all, SSA has no effect on prims. Technically the new setup wouldn't prevent you from applying temporary textures to prims, but it won't be possible to upload them any more, so there will be none to apply. The temp upload system was never intended to be a general purpose thing, it was there specifically for avatar textures. Since the new system doesn't need them any more, the local simhost asset servers are being discarded.

The name at the top, by the arrow, would be who it's from. This looks like is was ad-hoc conference chat. On newer viewers it's easier to create these, even without calling cards or friends list entries.

Hi, yes, you will need to stack up multiple hand models and show/hide. The morph target stuff is only available to the base avatar, it is not supported on uploaded meshes for now

You can't detect the key press, but you can periodically check llGetAgentinfo in a timer. AGENT_FLYING is intentional flying and probably the flag you want. AGENT_IN_AIR can be a useful addition if you want to catch the "accidents" too.

If you're trying to run a store and dont' want to spring for a whole region, it's probably not a bad idea to at least maintain a secondary location somewhere on the mainland. It's not all rainbows and unicorns on mainland, but your stuff will still be there tomorrow.

This happens when, an estate owner closes sims without warning, or can't pay the bills and LL shuts them down. The advice you got was the right stuff, contact LL and ask for the region to be temporarily revived so you can retrieve your stuff. Many poeple have good experiences with private rentals, but this kind of thing happens again and again. Only pay rent in for short periods, keep an eye on the estate for any signs of trouble, and think a while before you leave expensive no-copy stuff rezzed on land you don't get directly through LL.

You would have to use the rezzing workaround. There was once a feature request to allow attachments to jump to other points, but it didn't go anywhere.

There is a single water level for the region, any local changes have to be faked up with prims. If you have estate access, you can change the water level in World>Region/Estate, under the Terrain tab. Note that if your region is joined up with others on the map, it can look really really weird if they don't all use the same level.

Oh, I think you may actually be stuck, Check out these pages -- http://wiki.secondlife.com/wiki/ObjectUpdate http://wiki.secondlife.com/wiki/ObjectShape Taper is a signed 8 bit integer, meaning that the -1.0 to 1.0 we enter in the editor are scaled out to the range -128 to 127, as integers. So the real precision isn't the full 3 places we see in the editor.

Try big changes ... instead of from .498 to .5, try going to 0, then straight to .498 Small object changes are sometimes discarded, but the viewer relies on its local version of events until a server update comes through. The bigger changes are to help prompt the server into actually mkaing them.