Randall Ahren Posted May 27, 2011 Share Posted May 27, 2011 What's the best way to make clothing removable by another without having to use a collar or RLV? Is it possible to insert a script into an article of clothing that will cause the clothing to go phantom and transparent when clicked by another? That would be almost as good as removable, but it would probably be better if the clothing actually detached when clicked. Link to comment Share on other sites More sharing options...
Jacki Silverfall Posted May 27, 2011 Share Posted May 27, 2011 Yes. I have heard about this. The party types the command in the chat window and a piece of clothing comes off. That's all I know about it. Someone else might know more. :smileywink: Link to comment Share on other sites More sharing options...
Acheron Gloom Posted May 27, 2011 Share Posted May 27, 2011 You can use llDetachFromAvatar. https://wiki.secondlife.com/wiki/LlDetachFromAvatar I can put something together for you if you want, or if you have any knowledge of LSL I'd suggest you try to make it on your own. Link to comment Share on other sites More sharing options...
Randall Ahren Posted May 27, 2011 Author Share Posted May 27, 2011 I do have some experience with LSL scripting, but I have never used that function. From the description, it appears that the avatar wearing the clothing item must grant permission for the other avatar to detach it. That's close to what I want to do, but it would remove some spontaneity in role play. In the marketplace, there is this item: Cyn-h black pistache Undress silk bellydance papillon I would link to it, but I am unsure of the maturity rating. It looks pretty hot. According to the description, others "can click on your dress and undress one of those pieces if you allow them." Link to comment Share on other sites More sharing options...
Rolig Loon Posted May 27, 2011 Share Posted May 27, 2011 It's actually quite easy. To use llDetachFromAvatar, you need to request permission first, but since the wearer of the garment is the one who has to grant permission, that's easy. Once you (the scripter) have requested and received permission, all you need to do is make a touch_start event, check llGetPermissions in it, and then llDetachFromAvatar. Most scripted garments like that also pop up a dialog box for the wearer, so that s/he can block the detachment, but you could write the basic script without that part. Link to comment Share on other sites More sharing options...
Griffin Ceawlin Posted May 27, 2011 Share Posted May 27, 2011 Xcite! sells such a script that also has allow/ignore/set owner capabilities. No permissions are needed for someone that is designated as owner. Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 27, 2011 Share Posted May 27, 2011 Randall Ahren wrote: I do have some experience with LSL scripting, but I have never used that function. From the description, it appears that the avatar wearing the clothing item must grant permission for the other avatar to detach it. That's close to what I want to do, but it would remove some spontaneity in role play. Just to clarify, the script needs to call llRequestPermissions(owner, PERMISSION_ATTACH) once, in the attach event, to work at all. In addition, it's normal, when making them for sale, to include something that asks the wearer each time someone wants to remove your clothing, because you might not want that to happen every time someone clicks, or to include functionality to add blacklists and whitelists and so on, but that's not necessary for llDetachFromAvatar to work. So if you're happy that anyone can remove the item, possibly by accident, there's no need to have it bother you each time someone clicks it. Link to comment Share on other sites More sharing options...
Monti Messmer Posted May 27, 2011 Share Posted May 27, 2011 All this only works for prim-clothes. SL clothes can only be taken off by others via RLV. Link to comment Share on other sites More sharing options...
Acheron Gloom Posted May 27, 2011 Share Posted May 27, 2011 The attach permission is auto-granted on... attachments. So you wouldn't be bothered by anything, it would just do: llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); llDetachFromAvatar(); and that'd be the end of it. Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 27, 2011 Share Posted May 27, 2011 But there's no need to keep on requesting permissions, even though they're granted automatically. They persist, after all, so just asking for them when you attach the object (or even checking, when you attach the object, and asking for them if you haven't got them) would be sufficient. Having said that, I'd always -- as a safety measure -- check I've got the right permissions before actually doing anything, and request them if I haven't got them. Whenever I don't bother, someone always finds a way to lose the permissions, thus breaking things. Link to comment Share on other sites More sharing options...
Rolig Loon Posted May 27, 2011 Share Posted May 27, 2011 Innula Zenovka wrote: Having said that, I'd always -- as a safety measure -- check I've got the right permissions before actually doing anything, and request them if I haven't got them. Whenever I don't bother, someone always finds a way to lose the permissions, thus breaking things. I agree. It's an easy bit of idiot proofing to add if (llGetPermissions() == PERMISSION_ATTACH) to the touch_start event or, even better, to write run_time_permissions(integer perm){ if (perm & PERMISSION_ATTACH) { state running; }} and then put the touch_start event in state running, where it can't be activated unless the owner has granted permission Link to comment Share on other sites More sharing options...
Acheron Gloom Posted May 28, 2011 Share Posted May 28, 2011 Innula Zenovka wrote: But there's no need to keep on requesting permissions, even though they're granted automatically. They persist, after all, so just asking for them when you attach the object (or even checking, when you attach the object, and asking for them if you haven't got them) would be sufficient. Having said that, I'd always -- as a safety measure -- check I've got the right permissions before actually doing anything, and request them if I haven't got them. Whenever I don't bother, someone always finds a way to lose the permissions, thus breaking things. No, because permissions DO NOT persist after detach, so you do need to ask every single time, and it uses less memory, less bytecode, and less overall operations to use a single event rather than also throw in an attach event. The only way it would break is if it wasn't attached to the avatar, in which case you wouldn't expect it to work anyway... and if you want to add in error checking for that you would just do: if(llGetAttached()){ llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); llDetachFromAvatar(); } And you can't lose the permission considering its requesting it miliseconds before detaching, but if you want to be redundant: if(llGetAttached()){ llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); if(llGetPermissions() & PERMISSION_ATTACH){ llDetachFromAvatar(); } } Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 28, 2011 Share Posted May 28, 2011 They do persist, though, as is easily demonstrated with this example: default{ state_entry() { //llSay(0, "Hello, Avatar!"); } attach(key id){ if(id!=NULL_KEY){ if(llGetPermissions()&PERMISSION_ATTACH){ llOwnerSay("No need to ask for permissions again; got them already"); } else{ llOwnerSay("Need permissions; requesting them now"); llRequestPermissions(id,PERMISSION_ATTACH); } } } run_time_permissions(integer perm){ if(perm & PERMISSION_ATTACH){ llOwnerSay("got permissions now"); } } touch_end(integer total_number) { if(llGetPermissions() & PERMISSION_ATTACH){ llDetachFromAvatar(); } }} 1 Link to comment Share on other sites More sharing options...
Acheron Gloom Posted May 28, 2011 Share Posted May 28, 2011 Thats a surprise to me ;o. Does it do that for all permissions? And when would they dissapear? Could be slightly useful for me since almost everything I make uses permissions, and I always request on attach, when I can just request once on state_entry (due to the way my scripts work). I still think, however, that even having the attach event in the first place would be overall less efficient than only a touch event, since the event activating for attach/detach is much more to do than a quick and simple function, and it would take up more memory/bytecode. And if you're running in mono, the additional memory makes a difference (since mono dynamically allocates and LSL doesn't). Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 28, 2011 Share Posted May 28, 2011 Acheron Gloom wrote: Thats a surprise to me ;o. Does it do that for all permissions? And when would they dissapear? Could be slightly useful for me since almost everything I make uses permissions, and I always request on attach, when I can just request once on state_entry (due to the way my scripts work). I still think, however, that even having the attach event in the first place would be overall less efficient than only a touch event, since the event activating for attach/detach is much more to do than a quick and simple function, and it would take up more memory/bytecode. And if you're running in mono, the additional memory makes a difference (since mono dynamically allocates and LSL doesn't). I've not tested, but according to the wiki it looks as if all permissions persist, other than PERMISSION_CONTROL_CAMERA, until the script revokes them or is reset. Some TPVs let you revoke PERMISSION_TRIGGER_ANIMATIONS from the viewer, and there's a long-standing jira about making them release permisssions, VWR-13228, but as far as I know, under normal circumstances scripts retain permissions otherwise. I still always test, though, to make sure I've got them. I don't quite understand your point about Mono and memory. Eventually, we're going to be able to allocate memory with mono, or so we have been assured for the last couple of years, but I thought that, at the moment, 64k are allocated to every Mono script whether or not it needs them (as opposed to 16k with LSO). And, at least at present and of particular relevance to llDetachFromAvatar, SVC-3895, "Rezzing Mono scripted object cripples sim FPS", is a very good reason for not using mono in attachments unless you absolutely have to. Link to comment Share on other sites More sharing options...
Rolig Loon Posted May 28, 2011 Share Posted May 28, 2011 PERMISSION_LINK does not necessarily disappear when you stand up, so that's another instance where it's important to check. In the Phoenix viewer, at least, you have the option in Preferences >> Phoenix >> Shields to have permissions revoked (1) NEVER, (2) on SIT, (3) on STAND, or (4) on SIT and STAND. NEVER is the default, marked as "Original behaviour". Link to comment Share on other sites More sharing options...
Acheron Gloom Posted May 28, 2011 Share Posted May 28, 2011 Well, for one, a simple function barely is anything for the server to calculate. Events are actually a bit more script time, and operations, than just running a function or two. By that I mean you could just use a quick touch_start event and it'd be much more efficient for the sim. Second is that Mono, right now, does dynamically allocate memory. "Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. LSL2 allocates a full 16KB for all scripts, even simple "Hello, Avatar" ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes." That means that a very short script like this would only take 1,000 bytes of memory in Mono, but in LSL it would take 16,384. Third is that the mono rezzing in/out bug is being fixed quite soon, and Kelly has said: [16:06:10] Kelly Linden: mono will be better on sim performance. Though, yes, I am crossing my fingers Fourth is that if you use the script multiple times on multiple pieces of clothing, Mono has bytecode sharing: "Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script's size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory." Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 28, 2011 Share Posted May 28, 2011 I know that the idea is that we should eventually be able to specify how much memory we want a Mono script to reserve for itself, but I thought -- and I could be mistaken -- that at the moment, 64KiB get allocated to all Mono scripts, regardless of what they actually happen to be using at the time and regardless of how much they might ever need. I would have thought the fact the memory has been allocated to one script would mean it's not available to allocated simultaneously to another one. Am I mistaken in this? Link to comment Share on other sites More sharing options...
Rolig Loon Posted May 28, 2011 Share Posted May 28, 2011 Innula Zenovka wrote: I know that the idea is that we should eventually be able to specify how much memory we want a Mono script to reserve for itself, but I thought -- and I could be mistaken -- that at the moment, 64KiB get allocated to all Mono scripts, regardless of what they actually happen to be using at the time and regardless of how much they might ever need. Right. The confusion arises because someone at LL headquarters jumped the gun and inserted the language about dynamic memory allocation into their Mono page on the wiki as if it were a fait accompli. AFAIK, dynamic memory allocation is still on hold, waiing until the day when LL gets its act together and gives us the full package of script limit stuff. I think the same is true about code sharing, but I'm not sure about that. Void will be along shortly to give us the straight poop. Link to comment Share on other sites More sharing options...
Void Singer Posted May 28, 2011 Share Posted May 28, 2011 ::comes along:: oh hai! lol internally the 64k is always "available" but memory is still assigned dynamically in blocks... the ability to specify is just something that will allow cutting out the code that says "hey do we need to check on allocating another block" sooner, which will allow reporting it viewer side as well.... but even then, if we specify 64kb and only ever use 4kb... it'll report 64, and behind the scenes it'll still only use 4, but also continue to check if it needs to add more. this is done for consistency, without which things like script limits and reporting become almost useless, since you can't define what's what anymore or get an accurate read. what we see viewer side is just the reported cap, and not the actual usage (which is what those new profiler commands aim to tell us), internally, it's all dynamically allocated as blocks for MONO... LSO is straight up 16kb block, no variation, no bye sharing. as for permissions, it's possible to revoke just about all of them, and some are auto revoked depending on owner status or how they were obtained... (for instance I believe animate was changed to auto revoke if requested on sit, and then the av gets up, others I'm not sure about)... given the high usage of the one viewer that allows extended permission revocation, it's always safer to check your permissions at least on rez or attach Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 28, 2011 Share Posted May 28, 2011 So, leaving aside issues like the Mono rezzing bug, does this mean it's better to compile short, simple scripts in LSO or in MONO? Link to comment Share on other sites More sharing options...
Rolig Loon Posted May 28, 2011 Share Posted May 28, 2011 Tanshin Denothar wrote: Thanks for the responses, I'll have to look through them. If you guys have every played Riven you'll know what I'm taking about here. I'm trying to make a replica of the Firemarble Domes that you find in the game. I'm in the middle of rewriting the script and was going to give llTargetOmega a try instead of what I was doing previously (progressively lessening the speed of a texture animation). The issue we had there was that the animation would always click back into it's original place when stopped. Right, and that's what the Smooth Rotating Door code is meant to overcome. I guess that brings up another question then. Say we eneded up using a texture animation, is there an algorithm or some way to get that to automatically reduce in steps and stop at a certain point? Perhaps we can modify the solution posted before? Yes, you can get an animated texture to stop at a specific frame. See the last example at http://wiki.secondlife.com/wiki/LlSetTextureAnim. Again, though, getting the animation to decellerate gracefully is going to be the tricky and, in this case, perhaps impossible part. You could try calling llSetTextureAnim in a timer that changes the animation speed with each iteration, although I suspect the result could be choppy. It's worth a try, though. Link to comment Share on other sites More sharing options...
PeterCanessa Oh Posted May 28, 2011 Share Posted May 28, 2011 Confusion - I'm ill, my brain isn't working well :-( As scripts are all server-side how are TPVs able to revoke permissions? Link to comment Share on other sites More sharing options...
Void Singer Posted May 28, 2011 Share Posted May 28, 2011 without considering that bug, the answer is "most probably".... it's possible that the same simple short script will actually be larger in MONO than it is in LSO, particulary if it's function/math heavy instead of variable heave (exception, strings), but if it's a script there are likely to be multiples of, it will benefit from bytcode sharing. how that works, is essentially, the MONO engine uses one set of instructions, for all the duplicates scripts, and only has separate spaces for variables and the execution pointer (where each instance is at in the code), which actually saves memory, especially in math and function heavy scripts (not so much in scripts that maintain a lot of variables), plus it runs faster over all. considering the MONO insertion/removal bug (the insertion part of which is supposed to be fixed next roll) I'm still recommending LSO for anything that travels multiple regions, or (de)rezzes often, unless it just can't be made feasibly without MONO. testing on an near empty region with vehicles shows that while behavior is much improved, to the point that a very lightly loaded av is crossing in it there's no perceptible difference, a heavily loaded av still takes a performance hit by comparison... that said, if it's a choice between 3 LSO and 1 MONO script, you might as well go with MONO @Peter: because permissions are communicated through the server to the client and back. I'm not for certain if that ability was intended, or just exposed though... you'd have to ask someone more familiar with viewer coding, 'cause I avoid it like the plague Link to comment Share on other sites More sharing options...
Acheron Gloom Posted May 29, 2011 Share Posted May 29, 2011 The latest Mono2-Perf release notes stated that the removal bug would be fixed as well. Also the quote I added in my post is from Kelly saying that Mono will be better on region entry/exit than LSL. As I said before though, I'm still crossing my fingers. Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now