Innula Zenovka

I was concerned about this for a while, but when Firestorm adopted mesh, I started wearing the few mesh clothes I've liked enough to buy, and very few people have complained about them looking strange. The one time someone has, it turned out he -- a Phoenix user -- was the one person in the group of half a dozen of us who couldn't see them properly, and that was before Phoenix became mesh-capable. My advice is not to worry. I find this particularly ironic, in fact, when I remember how upset some Emerald, and later Phoenix, users became if they were wearing stuff on one of the "illegal" extra attachment points and someone complained their belt was floating round a metre or so away from them.

I find a good way of keeping up with new lsl functions is to watch the weekly release notes in the Second Life Server forum. They get announced there for the RC channels a couple of weeks (at least) before they hit the main grid.

This was discussed recently over at SLU. There doesn't seem to be a simple fix, but some of the workrounds might help.

Apart from the mesh-specific functions (to change prims to mesh, for example), the only new function I can think of that depends on using a mesh prim-type is llSetKeyframedMotion, which is still rather rough at the edges but lets you move non-physics linksets with the sort of smooth (and far less laggy) motion associated with functions like llMoveToTarget. I don't know what you consider "new," Phil. There's been a lot of new stuff over the last year; to my mind, the most immediately useful functions innovations have been llGetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast, along with a lot of new constants like PRIM_TEXT and PRIM_OMEGA (so you don't need to set hovertext or llTargetOmega for child prims with separate scripts), llLinkParticleSystem (set and control different particle systems for child prims all from one root script), llSetLinkTextureAnim, llLinkSitTarget and llAvatarOnLinkSitTarget. There's now very little you can't do from one main script in the root, which is great. And the new constants PRIM_POS_LOCAL and PRIM_ROT_LOCAL make moving child prims in linksets (including attachments) so much simpler than it used to be. There's also llRegionSayTo, which lets you do all sorts of fun stuff. It can be used as an alternative to llInstantMessage without the delay (if the target is in the same sim), prims can talk to each other using it, and also you can use it to talk to an avatar's attachments if you know the avatar's uuid (so it doesn't matter that everyone's RLV relay listens on the same channel; messages between my relay and the object that's trying to control me pass direct between each other, without other objects and other people's relays have having to sort out who they're for). And we've also recently had llCastRay, which is like a very tighly focussed, and far more efficient, sensor. It's at last provided me with a simple solution to the problem of how to make something hover n metres above the floor when the floor might be that of a skybox rather than at the sim's ground level. Probably best just to go to the main lsl functions page in the wiki and take a look at anything marked as "new" (which covers stuff introduced over the last year and odd, I think).

I'm not that familiar with Firestorm's automatically revoking permissions -- how well does it work for revoking permissions that you've explicitly granted to an object belonging to someone else, like the huds that do this, as opposed to those that have automatically been granted when you sit on something? Jahar's comments in the SLU thread you referenced (and Jahar certainly knows a great deal about scripting) suggest to me that it wouldn't, but I just don't know.

Preventing access to your land by very new accounts, at least temporarily, might be an idea. You could use something like this script in the wiki.

We had a lengthy discussion about it (or a similar device) here, too. Just to clarify -- and forgive me if you realise this and I'm misinterpreting your comments -- this exploit is nothing to do with anything you are wearing or any script or object that belongs to you. It's a script in a hud that this woman is wearing that's causing the mischief. It's a similar principle to a chim or a dance ball that belongs to someone else, which asks for permission to animate you and plays dances. Normally, when you want to stop dancing, you touch the dance ball again, or say /99 stop or whatever, and the script in the chim or dance ball stops animating you and releases the permission you granted it. The hud I'm sure this woman used starts and stops the animations, but, because it never releases the permissions, can start animating you again if she wants it to.

You can count the scripts you've got running, and find out how much memory they're using and so on, but I don't think you can tell what they actually are. However, this exploit doesn't depend on any scripts you own -- there will be a script of hers, almost certainly in the hud she used to offer you the hug, that's retained the permission you granted to animate you. ETA -- just to clarify, this exploit is nothing to do with RLV. It depends on native LSL functions. So if you still want to use RLV, this exploit is no reason not to.

The main avantage is that mesh viewers can render mesh objects and clothing properly, so you see a mesh object as it should be rather than as some odd-looking shapes. That's maybe not such a big issue now, because there's not a great deal of mesh to see on the grid, but I think that now even Phoenix has a mesh-capable version, we'll see a lot more mesh about before too long. Or, rather, we'll see it if we use viewers that can render it; if we don't, we'll find an increasingly number of places and avatars look very odd indeed. A side-benefit is that they have greatly enhanced graphics capabilities if you run your viewer with the graphics settings on ultra, assuming your system is capable of doing that. Doesn't matter if you can't run your viewer on Ultra -- just that, if you can, SL on Ultra looks pretty amazing. I can't really think of any disadvantages of using a mesh-capable viewer.

VRprofessor wrote: How are folks getting those hardware reports I see pasted into various threads? Not sure anyone will care about what I find, but since I asked for help it seems only fair to report back. Figure I should include the hardware info as part of my report. Help=>About in the viewer gives you the sim and hardware details.

The only I can think she can have done that is if you had somehow granted an object belonging to her permission to animate you. Had she used some sort of greeter on you, perhaps, that said she wanted to hug you, and you said yes? Or maybe you had sat on something belonging to her? Scripts retain animation permissions unless these are revoked somehow -- and it is possible (they're items on the marketplace that exploit this) to keep the permissions just about indefinitely. So long as you are not on the same sim as her, you're OK. But if you run into her and she tries it again, I would have no hesitation in ARing her. And it's worth contacting the landowner, too, if you run into her in a club or something and she does it -- certainly a lot of Adult places, at least, are very aware of this exploit and eject and ban people who use it.

It may sound a stupid question, but are your sure your L$ balance has refreshed in your viewer after the crash? I was puzzled by a similar message once until I realised my L$ balance hadn't loaded.

I'm sorry, but I have to along with the majority here, too. I don't see the advantage to running a loop as opposed to using ~llListFindList(list,[whatever i'm looking for]). In fact, I remember getting told off (in the nicest possible way) by Jesse Barnett in the old, old forums for not doing precisely that.

Can't really help with why it's happening, though Void Singer gave a possible explanation in this thread. There's a jira about this sort of tattoo layer funkiness that might be worth watching: VWR-25775

Marine Kelley makes the RLV viewer, which is available in versions of V1, V2 and V3; they're all basically the official viewer with RLV and a few other tweaks. All downloadable from http://www.erestraint.com/realrestraint/

PeterCanessa Oh wrote: "I bought xxxxx from you.", "Oh no you didn't, the money didn't get through" "I refunded you xxxxx and I can prove it", "Ahhh, I'll have to argue with LL instead" I don't see how it would work in the first of those cases, though. Yes, if I give a customer a refund or pay someone a commission on a sale, llTransferLindenDollars(destination, amount) will record the fate of the transaction, but how does it record anything about my customer's attempts to pay me?

That's simple enough to do. Set up your rezzer at ZERO_ROTATION (that is, with all the numbers in the rotation spinners in the edit window at 0.0). Place the object you want to rez where you want it to rez, in relation to the rezzer, and rotated how you want it. Make a note of the numbers in the object's rotation spinners. In your rezzer script, make a global variable, rotation rot. Give rot a value in state_entry() with the following calculation rot = llEuler2Rot(<x,y,z>*DEG_TO_RAD); where x, y and z are the three values from the spinners. then alter the line that rezzes the object to something like llRezAtRoot(object_name, llGetPos()+offset * llGetRot(),ZERO_VECTOR, rot * llGetRot(), start_param); The fourth parameter, rot * llGetRot(), tells the rezzer to rez the object at the specified rotation relative to how the rezzer itself is rotated, so you won't need another script to rotate the object after it's been rezzed. Make sure the rezzer is at ZERO_ROTATION when you take the initial reading, and also make sure you do the multiplication rot * llGetRot() (the order does matter in rotation calculations).

The first thing to check, then, is whether you're under any RLV restrictions that stop you accepting teleport invitations. In Phoenix, you should have a menu up at the top for RLV. Click on that, and somewhere on it there's an option to Show Restrictions. That opens a little window that shows you what RLV restrictions, if any, are in place and the name of the item that's imposed them (probably, since it's persistent, something you're wearing, like a collar). Does it say anything about "@tplure"? If it does, that's the problem. You need to remove the object that's responsible for issuing that command.

From the point of view of performance, I've always found the tips here very sound. And even though it's an old article, in my experience the advice on disabling Antialiasing in the viewer and, instead, telling your graphics card to do it, is increasingly important. Simply turning it off in the viewer and telling my Nvidia card to apply Antialsing x 4 when it's running SL pretty much doubles my fps in ultra in the more recent viewers.

I've been trying to think when I might want to use it. I mean, the most common reason for llGiveMoney failing is if the money isn't there, and the most common use for llGiveMoney is to pay a percentage of something that's just been paid to the object (a tip jar or a commission vendor) so that's not normally an issue. I am sure there are times it will be really useful, but I can't think of one off-hand.

Since a script can't do anything unless it's in an object that is rezzed in world, I'm wondering if this "Syntax" thing isn't an attachment the OP was persuaded to wear, which is somehow designed to crash the viewer on_rez by flooding it with llDialog menus or something. That would explain what I think is being described. If that's the case, trying to relog in a no script sandbox might let you in, and then you could remove all attachments and get rid of the thing that's causing the problems.

The only way I can think that your rug would suddenly stop being a rug and turn into "a funny shaped box" is that when you were trying to resize or retexture it, you managed to change the object from being a sculpted prim to being a box by changing the drop down for "object type" Did the object tab start by looking like this and end up looking more like this? Try switching it to Sculpt and see what happens, anyway.

The blog FabFree might be worth following. They cover freebies, group gifts and hunt prices for both men and women.

There's a number of reasons for this error message (see Maestro Linden's comment in the jira). The short answer is that it can be caused by trying to something that is, itself, trying to rez things (a temp rezzer or some forms of teleporter), in which case your friend might have better luck in a no-script sandbox. Or it could be a temporary problem with SL -- I now and again get that message on my home sim, but if I try half an hour or so later, the problem seems to resolve itself. Otherwise, as I understand it, your friend will probably need the assistance of a Linden to resolve the matter. ETA -- I doubt this is because of Linden trees, myself; when that's the problem you get -- or I did, the one time it happened to me -- a very specific message telling you that you can't rez Linden trees in that parcel (or words to that effect).

I don't know about "main" but certainly an important reason might be that the "industry and media expectations" were, on any sober analysis, unrealistic, I guess. What was the main reason for the dot-com bubble?