Innula Zenovka

As people may have heard, Stroker Serpentine has released his SexGen Ultra Base 5.0, plus 600 animations, full perms. He didn't make all the animations, and there's been some doubt raised about whether builders are entitled to use the animations not made by Stroker himself. I don't know, is the answer, and it strikes me that the prudent -- and, certainly, polite -- thing to do would be to ask the creators concerned if, and under what conditions, you're allowed to use their creations. To assist people with this, I have checked -- by script, I hasten to add; I'm not so obsessive as to do it by hand -- the creators of all the animations not made by Stroker himself. The results are to be found in a Google spreadsheet at http://tinyurl.com/662rktd ETA -- by request, I've put up an additional spreadsheet, showing which animations were made by Stroker himself, as well as the others, at http://tinyurl.com/5wk3mr2

I vaguely remember asking Live Help about something similar a couple of years ago. They obviously won't discuss the status of the owner's account, but if they've closed the sim because of non-payment, then, if you ask live help (or put in a support ticket) they should let you in to retrieve your items before they delete the sim. While I can't swear to it, if they actually delete the sim, I think they delete everything on it at the same time, regardless of who owns it. So you need to move quite fast.

The reason I use an external service is that, that way, I don't need to worry about what happens if my server ever needs to be re-rezzed.

I'm afraid I don't think llGiveInventoryList gives no-copy items under any circumstances, whether it's attached or not. The only work-round I can think of -- and I've used it pretty successfully when I want products I'm selling to give out props that I don't want to make copy-transfer -- is to use llHttpRequest to send a message, via an external service, to an in-world server telling it what to send and who to send it to, and have that send out the objects in question. I'm wondering if a variation of that would work. It sounds complicated, but, in practice, I was very pleasantly surprised at how easy it was, using this example in the wiki as a model to adapt. They even provide the external service, which was very useful when I was testing it.

A better analogy might be with asking several different people how to make a cheese omelette. All the recipes are going to involve beating eggs, grating cheese and using a frying pan, but are likely going to differ considerably in precise detail. Following any one of them will probably give perfectly acceptable results, but mixing and matching probably won't. Just pick one you find easy to follow and which gives results you like.

Depending on the circumstances, I've found llCastRay can be very handy for calculating where the floor is (that is, if there's nothing between the object casting the ray and the floor, that is) when llGround isn't any help. It tells you where you hit the target, which is convenient because you can offset from that rather than worry about the object's size. But it also -- which threw me till I realised that's what happens -- detects prims in the same linkset as the script casting the ray, so you need to be aware of that.

Two things. First, I don't know how you're calculating ownerheight, but the offset I use (which I think I originally found here, in the old forum) is vector agent_size = llGetAgentSize(llGetOwner());vector object_size = llGetScale();float foot_bottom = -1*((agent_size.z*1.1)/2);//distance from agent centre to bottom of feet //works for most avatars, believe it or not Second, remember your formula is going to put the middle of the object at the owner's feet, so you might want to subtract half the z value of llGetScale() from the position, too.

Go to https://my.secondlife.com/settings/privacy while you're logged in and find this tab: Set the top drop-down for your "Feed" to Friends (as I have done) or to "No one". Then no one but your friends (or no one at all) will be able to "follow" what you post on your wall, which is what the "follow" thing is about.

Void Singer wrote: I didn't see it as detraction, but rather a sidebar. pretty sure OP got all the info they needed.especially since defamation would require an actual false statement, the picture policy is more likely to get results. now we're just in it for the interesting inconsistencies of LL policy (well I am) I think that for LL's purposes, as opposed to those of the law of libel, the fact that a statement is derogatory probably counts as "defamation". I bet if I put up a board in-world saying "So-and-so is a lying, cheating scumbag" and so-and-so ARd it as harassment>defamation or whatever it's called, LL wouldn't offer me the opportunity to prove it was fair comment before they returned it.

Rolig Loon wrote: Anton Hammerthall wrote: Setting the temporary variable doenst work, it still gets in you inventory. It does? It doesn't do that for me. When my temp rez objects die, they stay dead. They don't get resurrected in my inventory. Even when you detach them, as opposed to drop them on the ground? I can't get that to work.

My bet would that, in general, people paid at least the asking price, and many people probably paid more. But my assessment is strongly influenced by the fact you have -- and rightly so -- a very strong and loyal customer base and that you and Rivan are very much part of the brand. People know that anything you make is going to be very good quality, imaginative and great fun, and they'll enjoy excellent customer support, and, in consequence, are generally going to be very unwilling to tell you, in effect, "it's not worth what you're trying to charge," if they paid less. So my guess is that, rather than be cheap, and cheap to someone they know, at least through your very active product support group, and whom they like, most people will either pay at least the price you suggest, or not buy it at all. I'm not sure, though, that an unknown creator would have a similar experience.

Sorry, but you can't sit on something that's attached to another avatar. The only work-round I can think of, offhand, is to try having the chair ask to animate the other avatar and then for the avatar to maneuver him- or herself into position on it, but I'm not sure how well that would work in practice.

While Void's method is by far the best and simplest way of making a door or lid I know, I had a shot at writing a script for an uncut lid prim (which sometimes you need -- if, for example, the lid can't be cut because it's a sculpted prim and the axis is in the wrong place). This makes the lid prim pivot on the bottom edge of its own side 4, the side the red arrow goes into in local ruler mode, no matter how the prim is rotated on the box. The script can go in either the lid or the root prim; the lid must not be the root, though. And the box will only open and close if you touch the lid. Put the word "lid" (no quotes) in the description field of the prim, so the script knows which prim it's supposed to move. //expects a single uncut box prim as the lid, pivoting on the bottom edge its side 4 (lesser x side)integer lidLink=-1;integer lidSwing =-90;rotation rotLidSwing;rotation lidRot;vector lidPos;vector lidSize;find_prims(){ integer max = llGetNumberOfPrims()+1; while(max--){ string s = llToLower(llStringTrim((string)llGetLinkPrimitiveParams(max,[PRIM_DESC]),STRING_TRIM)); if(s=="lid"){ lidLink=max; lidSize=llList2Vector(llGetLinkPrimitiveParams(lidLink,[PRIM_SIZE]),0); return; } } if(lidLink<0){ llOwnerSay("can't find a lid prim"); }}default{ state_entry() { find_prims(); rotLidSwing = llEuler2Rot( <0.0, (float)lidSwing * DEG_TO_RAD, 0.0> ); } changed(integer change){ if(change & CHANGED_LINK || change & CHANGED_SCALE){ find_prims(); } } touch_start(integer total_number) { if(lidLink<0){//sanity check find_prims(); } if(llDetectedLinkNumber(0)==lidLink){ list params = llGetLinkPrimitiveParams(lidLink,[PRIM_POS_LOCAL,PRIM_ROT_LOCAL]); lidRot=llList2Rot(params,1); lidPos=llList2Vector(params,0); vector offset = <lidSize.x*0.5,0.0,lidSize.z*0.5>*lidRot; vector pivot = lidPos-offset; llSetLinkPrimitiveParamsFast(lidLink,[PRIM_ROT_LOCAL,rotLidSwing*lidRot, PRIM_POS_LOCAL,pivot+<lidSize.x*0.5,0.0,lidSize.z*0.5>*rotLidSwing*lidRot]); rotLidSwing= (ZERO_ROTATION / rotLidSwing); } }}

I wonder what the policy is on using llSetPrimMediaParams to bring up people's whole profiles on a prim rather than displaying their pictures as a texture.

Qie Niangao wrote: I'm pretty sure the "silly rule" wasn't about defamation, but rather about the use of profile pictures. That rule is silly because its legal grounds, copyright, bears no relationship to the actual reason it exists: to placate a small segment of the public who imagine it protects their privacy (although it does nothing of the sort). The idea that the prohibition on displaying people's profile pictures protects anyone's privacy seems a bit misguided. The only person to whom it discloses the fact I've been in the shop of the club who wouldn't know anyway is someone who arrives soon after me after me, assuming I've left before they turn up, until someone else consents to have his or her profile picture displayed. Despite this, as far as I can see there's absolutely nothing in the ToS to stop someone putting out a prim that displays with hovertext the names of the last 10 visitors, which seems far more invasive.

There's an issue with the advanced one, in that it only works for full-perm objects (because it tries to read the texture uuids for both the sculptmaps and the textures on the prims, and it can only do that if the object is full perms for the owner). I'm a bit surprised you couldn't get the basic one to work (it works fine for me), but try this. You have to put it into the prim you want to phantom before you link it up, and that prim must not be the root prim. The script will work its magic and then delete itself. This method can cause strange behaviour if other scripts in the build are trying to detect collisions, but, other than that, it should do the trick. default{ state_entry() { llVolumeDetect(TRUE); llRemoveInventory(llGetScriptName()); }}

Is this a question about the library Simple Leash Script or about leash scripts in general? (If it's the former, it might be better as a comment to the library script, and if it's the latter, it really should be in the Scripting Tips forum, along with details -- if you have them -- of what leash system you and your sub are using.) What you describe sounds to me as if you've got a mixture of emitter and target scripts from different systems, which I would expect to cause the problems you describe.

Maybe I'm missing something, but aren't sit target rotations local to the prim anyway? This works for me, putting my back to side 0 of the prim and with side 3 facing the ground: default{ state_entry() { llSitTarget(<0.0,0.0,0.2>,llEuler2Rot(<270.0,180.0,270.0>*DEG_TO_RAD)); }}

There is a jira about it, but nothing seems to be happening: https://jira.secondlife.com/browse/VWR-14246

If it's on his sim, I'd AR the "Wall" on the grounds it constitutes Harassment => Disclosure and Harassment => Defamation. That should at least mean a Linden gets to look at the screenshot accompanies the AR.

Mauricette Morane wrote: @Innula Ooooh, thank you, that sounds good, but what on earth is RLV? The only reference I can find to this acronym is something to do with a separate viewer for a very specific purpose, so - if that's what you're referring to - I'm not sure how I'm supposed to "turn it on". Is there more info out there?  The Restrained Love API was originally created by Marine Kelley for her Restrained Love viewer but has been adopted by several other third party viewers, either in Marine's implementation (by Dolphin and Cool VL) or in Kitty Barnett's implementation, known as RLVa (Kitty's own Catznip viewer, Singularity, Firestorm and Phoenix). Imprudence also supports it, but I don't think they've updated it for ages (though I could be mistaken there -- I would be very happy to learn I am). When activated, the API lets scripts control aspects of your viewer that normally you have to control manually. It does this by responding to instructions issued by objects belonging to you, using llOwnerSay. However, the API is not normally activated by default in viewers that support it (it is in Singularity, but I think that's the only one). That is, after installing Firestorm or whatever you have to "turn RLV on," as I rather inelegantly put it, by locating the appropriate setting in your viewer preferences -- exactly where it is and what it's called varies from TPV to TPV -- and setting it to respond to RLV commands and then relogging. If you can't find it in your viewer preferences, you should always be able to find restrainedLove in the debug settings of your TPV. Set that to TRUE and relog. Note that only items you own can control your viewer. In order for other people to use my viewer's RLV capabilities to capture me or strip me or whatever, I have to be wearing an object that I've set to allow them so to do. So if the only RLV item you're wearing is your own hud for changing windlight presets, you don't need to worry about other people being able to exploit the fact you're got RLV enabled ( just be careful about accepting offers of collars from people!). Please feel free to IM me in world if you need any help setting up RLV. If you'd like, I'll drop you off a simple preset-changer to show you how it's done.

No, the only way to stop someone taking off an item is to make it undetachable using RLV. If you log on with a non-RLV viewer, then existing RLV restrictions stop having any effect and you can take stuff off in the normal way. What you could do with an Open Collar, and what I imagine Marcus did, is disable the "runaway" command, which, under normal circumstances, lets you remove your master or mistress, along with any RLV restrictions, and return it to the default settings regardless of any restrictions you may be under.

Thanks so much Marcus.. that's really helpful. I wasn't sure if muting the owner would do it, and it's rather depressing to find out it won't.

I thought it looked a bit odd, but maybe it's to avoid breaking the permissions by trying to animate someone who's not on the same sim -- that is, if you can't find them, don't try to animate them. If that's the reason, I realise there's a better way of doing it (test for llGetAgentSize), but I can't think why else the 96 meters restriction is there.

Here's an alternative way of doing it, which makes it warn you and then detach itself if it's attached to the avatar. Not tested, but I think it should work. default{ on_rez(integer start_param) { if(llGetAttached()==0){ state running; } else{ llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } attach(key attached) { if(attached){//i shouldn't be! llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } run_time_permissions(integer permissions) { if(permissions & PERMISSION_ATTACH){ llOwnerSay("You must rez me on the ground"); llDetachFromAvatar(); } }}state running{ state_entry() { //do explosives stuff llSleep(2.0); llSay(0, "This is a funny candle, it's sparkling!?"); llSleep(1.0); llPlaySound("dynamite", 1.0); llSleep(5.0); llPlaySound("dynamiteboom", 1.0); llRezObject("spark", llGetPos()+<0,0,0>, <0,1,0>, <0,0,0,0>, 0); llWhisper(666,"blowup" ); llSleep(2.0); llDie(); }}