• Announcements

    • Xiola Linden

      The New Community Platform   03/21/2017

      We are still working on making adjustments and changes to the new platform. Thanks  to everyone who has been sending in feedback and filing any bugs you've encountered! 

Innula Zenovka

Advisor
  • Content count

    8,346
  • Joined

  • Last visited

Community Reputation

1,426 Excellent

About Innula Zenovka

  • Rank
    Advanced Member
  1. If the two scripts are in the same object, then you could trigger the texture change by having the first script use llMessageLinked to send a message to the no-mod script. The message can contain any arbitrary integer (as its second parameter) or word (as its third parameter), and the no-mod receiving script, in its link_message event decides what to do about the message, either using if ... else if ... logic or simply by looking up the code-word or -number in a strided list and seeing what texture it means.
  2. The description of the product in the advert does mention that a specific mesh head is used, though I think that must simply mean they used the mesh head in the product picture, so don't be surprised that the shape's head is nothing like what you see illustrated. And the advert does say, quite clearly, However, since the shape is mod, I don't see why you can't play with the face to get it looking how you want, which is what most people do any way, unless they go for mesh heads. I spent years tweaking my avatar's face until I got her looking as I wanted, and I still play around with the settings when I get a new skin or new hair. Modifying your avatar is part of the fun of SL, I think.
  3. While you can stop animations by using either the name of the animation or its uuid, you can call them only by name. I think llStartAnimation("b43c9176-112c-944f-33fa-da2d275a9ac"); is going to trigger a script error message complaining it can't find an animation called "b43c9176-112c-944f-33fa-da2d275a9ac". When I want to stop a looped animation like that, I use the built-in system animations, which you can call by name without having them in the objects's inventory. So I call llStartAnimation("stand"); when the avatar stands up. If the avatar is using an AO, then the AO will kick in almost immediately and cancel "stand" (which is priority 0, so it's as low as it gets). If not, at least the avatar is standing rather than stuck in the looped animation.
  4. I think it's worse than that. The script keeps its animation permissions unless it's told to release them (or the script is reset). Normally that wouldn't be a problem since, as you say, the avatar's AO is going to start playing a stand or walk animation as soon as the dancer gets up, and most animation scripts won't try to do anything to the former sitter after she's stood, even if they don't explicitly stop the animation. However, since the start_dancing() user function never gets told to stop, I think what's likely to happen is that the script is going to keep on animating the avatar for as long as she's on the same region, or until someone else sits on the prim. Even then, though, because of the llSleep(), the script isn't going to know about the next sitter until the end of the current animation, so I suspect the second sitter is probably going to get up again before anything starts and then be surprised to find herself animated some 10 seconds or so later.
  5. The big problem is that you never do anything to stop the animations. Your user function start_dancing sets dancing to TRUE and then enters an infinite loop, while (dancing), which is always going to evaluate as TRUE because nothing can make it FALSE. There's an additional potential problem, in that since you cause the script to sleep for the length of each animation, even when you fix the main problem, the script isn't going to be able to do anything until the clip that it's playing has finished. If I were writing this, I would get rid the llSleep call and using a timer, instead. (always a good idea, to my mind, if you find you're putting the script to sleep for any longer than 0.5 seconds or so). So, in the changed event, if there's an avatar sitting on the object, I would ask for animation permissions and then, in the run_time_permissions event, I would start the first animation and set a timer for the length of that animation. Then in the timer event, I would step through my animation list, starting a new timer for each clip, and then go back to the start, as you do in the user function. To stop the dancing when the avatar gets up, simply call llStopAnimation in the changed event if there isn't anyone sitting on the prim any more, and then stop the timer.
  6. There's no way to "monitor inbound TPs" (if by that you mean teleport invitations sent from another region) unless you have access to LL's server logs, which presumably record such traffic. Otherwise, no. The only way the landowner, or anyone else, knows about tp invitations sent to third parties is what the third party chooses to say about them (which may or may not be the whole story, of course).
  7. A couple of points, in addition to Maddy's and Rolig's. First, you can't call llGetAgentList up in the declarations section (at line 1). If you try, it won't compile. You can use lsl functions only in the body of the script. Second, if you want a menu giving the names of all the avatars on the region, you want to populate it at run time, since the region's population is subject to change. While I agree with Rolig that this is a case where using numbered buttons makes more sense, here's how to do it if you want the names (or at least the first 10 or 12 characters) on the buttons. Note that this fragment obviously won't work on its own -- it's just to demonstrate how to build the list you need in order to populate the menu, and then to find the uuid of the avatar whose name you have chosen (since you'll almost certainly need that, not their name, to do anything with your menu choice).. list lUUIDs; list lNamesAndUUIDs; list lNames; default { state_entry() { } touch_end(integer num_detected) { lNamesAndUUIDs = [];//clear existing list list lButtons =[];//clear existing list list lUUIDs = llGetAgentList(AGENT_LIST_REGION, []);//list of all agents on the region integer max = llGetListLength(lUUIDs);//length of list integer counter = 0; do{ key k = llList2Key(lUUIDs, counter);//get each uuid in turn lNamesAndUUIDs+= [llGetSubString(llGetDisplayName(k),0,23)]+[k];//and add the username of that uuid and the uuid to lNamesAndUUIDs //truncate the names to their first 24 characters, the limit for buttons (though only the first 10 -- 12 characters will display) } while(++counter < max); //now, we need to populate lNames lNames = llList2ListStrided(lNamesAndUUIDs,0, -1, 2);//pull out the name component in lNamesAndUUIDs and add it to the buttons list //now do stuff to build a multipage menu, open a listener and on, using lNames to populate the menu buttons.. } listen(integer channel, string name, key id, string message) { integer n = llListFindList(lNamesAndUUIDs, [message]);//is the message an item in lNamesAndUUIDs? if(~n){ // shorthand for "if it is an item in the list". If it is, key k = llList2Key(lNamesAndUUIDs, n + 1);//find the next item, //and thus you have the avatar's uuid. } } }
  8. I've mentioned this during previous spam attacks in Lithium forums, but it bears mentioning again. Over at SLU, Cristiano (the site owner) quietly gives selected forum regulars the ability to ban spammers with accounts less than a month old. It doesn't actually ban anyone, but it does hide all their posts and all threads started by them, and removes their ability to post anything else. Cris then reviews the ban when he gets a chance and either makes it permanent or rescinds it. Cris makes it very clear that this power is to be used responsibly, for spam posts only, and that people who have this power aren't allowed to use it for any other purpose -- they have to report in the normal way any other posts they think are breaking forum rules. It works very well, and people don't abuse it.
  9. For this kind of dummy sensor I use llSensorRepeat("nobody",llGetKey(), AGENT_BY_USERNAME, 0.1, PI, 1.0); That can never fire, since it's looking for an avatar with the same uuid as the object containing the script.
  10. It's difficult to say without the script in front of me, but the problem sounds as if it's caused by using llGetDisplayName() to find your name when first you wear the hat but then using something else (llGetUsername()? llKey2Name(llGetOwner())? -- there's lot s of possibilities) in the money event. Simplest fix, to my mind, is to have a global variable, strOwnerName, and set that in the attach event, thus: string strOwnerName; default { state_entry() { strOwnerName = llGetDisplayName(llGetOwner()); } //stuff attach(key id) { if(id){ strOwnerName = llGetDisplayName(id); } } } and then simply use strOwnerName in your hovertext and chat.
  11. Thanks, Tommy! I've long thought an ignore feature would cut down on needless forum drama.
  12. llsleep()

    To search the ancient forums, follow this link and use the search box there: http://forums-archive.secondlife.com/-1/1.html
  13. llsleep()

    I've been searching the old, old forums via the search tool at http://forums-archive.secondlife.com/-1/1.html. Two discoveries. First, llSleep and resources (this is something I dimly remembered from years ago). It would appear, according to this discussion, that llSleep is quite resource-intensive, since it seems to be a sort of infinite loop. That's based on what LL devs apparently said during the course of a presentation. The video link there to the presentation works, and I've downloaded the file, but since it's an hour and 20 minutes long, I haven't had a chance to listen to it yet, so I know only what the summaries there say. But the participants in the discussion are people I remember as being very experienced scripters, so I trust their summaries. While I don't know enough to comment with any certainty about which solution is the least resource-intensive, I think it would be fair to say that llSleep doesn't seem to be without its own resource implications. It not simply a matter of turning the script off for n seconds. Second, llSleep and the event queue. I don't know if this thread is the one @Rolig Loon meant (I had to used a link shortener since the original didn't want to embed) but in it Void seems to be saying that touch and collision events are treated as simultaneous if they occur within 0.1 seconds of each other and also, in the specific context of llSleep, that they do stack in the event queue while the script is sleeping, but only one touch or collision event per avatar. So it sounds as if I'd have recorded two touch/collision events had I been testing things with a friend.
  14. It's used in a collar to constrain movement, to force the wearer to a specific spot and stop her moving away from it, or to make her follow the person holding her leash. It's also used in hug/kiss attachments to get the hugger and huggee close enough to each other. I can see how it could be used to affect movement speed but it just seems to me that llApplyImpulse and llSetForce are going to far simpler to use if you want only to slow down (or speed up) the avatar's normal walking pace. You''re not interested in where the avatar wants to get to; after all; you want only to make it more difficult to move in that direction. So you need only to set the second parameter, LOCAL, to TRUE and specify the vector (<-n,0.0,0.0>) and the simulator does all the calculations for you. As a general rule, though, attachments, including HUDS, can use any of the physics movement functions to move the wearer about (avatars are physics-enabled, but not change her rotation (unless RLV is involved. Non-physical movement functions move the attachment, not the avatar.
  15. llsleep()

    Is that how it works? If I walk into the object and then walk into it again a second later, surely that's two separate events? I could well be mistaken, but I think the number_detected parameter is relevant only if two collisions take place at the same time. Certainly the only time I've ever found it particularly relevant is in sensor events.