Jump to content

Clothing Removable By Another?


Randall Ahren
 Share

You are about to reply to a thread that has been inactive for 2703 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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

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

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


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

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


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


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

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();        }    }}

 

  • Like 1
Link to comment
Share on other sites

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


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

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

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 :S

 

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

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


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

::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


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
.  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

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

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

You are about to reply to a thread that has been inactive for 2703 days.

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
 Share

×
×
  • Create New...