Jump to content

A script that disappears objects!

Prokofy Neva

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

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

Recommended Posts

A script that disappears objects when you don't expect -- and they are lost forever! Not in trash, not in lost in found, but gone! I lost a single-copy rare this way!

I came across this item -- I think it's some years old from the beginning of the mesh era -- called "history of mesh -- expert Linden". It's made by amelie knelstrom (creator of vespertine) and called RezeeControl. You click, and it goes right into your hand, it's a cute little notebook.

It seems to be a freebie with a copyable and transferable script, but it's not modifiable sadly so I can't put it here, but IM me in world I'll send the item.

The reason I took it out and tried to put it in other objects is because I have been looking for a long time for a script that will put objects right into people's hands when they click on them, if "avsitter" the experience is enabled on that parcel.

For more than a decade we've had "give all" or "give on touch" or whatever, but the drawback there is that the item comes in inventory, and then someone has to drag it out to use it, and this can be annoying or confusing for newbies.

So naturally I'd like food to be able to go right in their hand. I think perhaps this could have been related to "disappearing food" but I'm not sure.

What I'd like to do is have a script that does not disappear things forever, and just keep that function that goes in your hand (or maybe someone knows another).

If you don't believe me, test it with a prim that you don't mind losing.



Link to comment
Share on other sites

To prevent people from using a script in other creations, it's a simple matter to have the script in the State Entry, on_rez state or when reset to check the name of the object it's in and/or it's creator and delete the item if it was removed from an item and put in another item.

This function will attach an item to an avatar but it doesn't go into their inventory.  It just disappears when detached. 


This function will attach an item to an avatar and when detached will remain in the inventory of the avatar.


Both require permissions to attach and also to animate the avatar if there is an animation involved upon being attached either before the item attaches or as part of an 'experience'.  Also note that you will also need to have a script that rezzes a fresh object anytime the one displayed is attached to the avatar or someone sits or changes an animation, the way avsitter does, as it only attaches the visible copy and does not make another copy for display. 

Note too that you will need to have copy and transfer permissions for the item in both circumstances, and if you are going to sell this creation, the next owner must have copy and transfer permissions.  Of course this eliminates any gotcha items as they are copy or transfer but not both.   Some full perm creators allow the temporary attachment of items that don't go into the avatars inventory and some do not.  Check with the creator if it's not clear in their license.

AVsitter may have both types of scripts in their package or available as an add on.  If not, I believe they give instructions on how to integrate your own script into AVSitter though lines in the config notecard or by use of an API script. 

You can write the script yourself or if you don't want to or can't, post in the Inworld Employment Section to have one written for you.  There may be some on the MP too.

Link to comment
Share on other sites

This is all trickier than one would want, the complications to avoid abuse by griefers.

First, of the two flavors, the non-temp llAttachToAvatar() only works for an item already owned by the person to whom it will attach. The least-clumsy user interaction for that was to keep a copy of the to-be-attached object rezzed for the wearer to buy Original (for L$0) on left-click and then its script could detect CHANGED_OWNER, ask permission and attach. Pretty clunky (and a copy is left behind in the wearer's Inventory).

The newer llAttachToAvatarTemp() doesn't go into the wearer's inventory and just disappears when detached. It however is owned by the wearer (unfortunately) for the time it's attached (or failed-to-attach) and except in Experiences, it does need to explicitly ask permission to attach.

The AVsitter Experience uses llAttachToAvatarTemp() to push attachments on Experience-enrolled sitters without asking for that specific, per-attachment permission (for which it must still ask those sitters who do not grant Experience permissions). It's very slick, but yeah: the item will go away when detached and so the script requires that to-be-attached items have both copy and transfer permissions (with a slight twist).

I had assumed, perhaps erroneously, that AVsitter only did this for sitters, but I see that the responsible AVprop plug-in can also function as a "standalone prop rezzer" so now I wonder if there's a way to use it to temp-attach on touch, without sitting. (That would be handy for all those enrolled in the AVsitter Experience, but at first glance it seems it would be vulnerable to griefers with AVsitter scripts.) AVsitter does provide a very extensive API for scripters, but naturally that does not include the ability to compile one's own (potentially griefy) script into the AVsitter Experience.

TLDR: the "lost forever" thing is built-in to the script function for attaching without permanently transfering ownership, so there's really no way for a script to let others hold a rare, no-copy object and then take it back afterwards, if that was the idea. (My rejected jira, referenced above, would have allowed attachment without even temporary transfer of ownership, so might have been relevant to this.) But for attaching objects that can be Copy+Trans and that can "poof" when detached instead of going into inventory, it's easy -- and with an Experience, seamless to the wearer.

[EDIT: Indeed, my assumption that sitting would be necessary for the AVsitter prop-attachment Experience was erroneous. In fact, it works just fine triggered by a user script messaging an [AV]menu plugin, to attach to any arbitrary avatar -- a toucher, collider, innocent bystander, etc. So that's still temp-attachment, probably not relevant to the request in this thread, but interesting to me, and useful for demos, food item dispensers, and other stuff.]

Link to comment
Share on other sites

I don't want to commission a script at this time.

I think getting food items into your hand is such a ubiquitous function that it should be an open script.

I'm not even a big fan of open source as many know, mainly for the culture of hatred of proprietary items and copyleftism that goes with it.

But I do believe that certain tools of the virtual world that are basic to its functioning, like notecard givers, should be open to use.

So just as "give all" is an open script, "attach to hand temporarly" should be. I'm not sure how that would be best set up, with objects that are copy but not transfer that come out of, say, a tea pot and copy temporarily to whomever touches them, or with transfer objects that go in their inventory. But the whole point is to avoid inventory clutter and confusion, so the latter would be preferable.

Link to comment
Share on other sites

Prokofy Neva wrote:

If the object was my own object, though, why would it disappear my object?

If it used llAttachToAvatarTemp, that would happen regardless of ownership.

But I'm still not completely understanding the goal here. Attaching your own no-copy object, always only to yourself, is a rather different function from attaching copy+transfer items to others. (Those are both possible, and it would even be possible to combine those functions in a single, somewhat complex script, but it's pretty unlikely anybody has ever actually written such a script that does both those different things. The latter is more typical, and I only just realized how easy it is to do on top of the AVsitter Experience, so if that's all that's really needed, it wouldn't be a big deal.)

[ETA:  There's still a prickly licensing problem here, though. It's more manageable for folks whe have full perm on the items to be attached but can directly set the next-owner perms according to the item creator's specifications. This all goes to hell, though, if one wants to go a level further in the supply chain and distribute the rezzers that give the items to end users. I'm guessing this isn't a problem in the current application, but it's a major limitation of how SL permissions work, effectively destroying value of those full-perm items because there's simply no safe way to distribute them inside a product (slam bit notwithstanding).]

Link to comment
Share on other sites

What you are looking for is llAttachToAvatarTemp. It gives a toucher/wearer the ownership for a while but doesn't leave a copy in his/her inventory. The object disappears only when the wearer took it off, though usually I add a timer or CHANGE/CHANGED_TELEPORT to trigger llDetachFromAvatar for some reasons.
Wiki has a free sample script for you.

Vespertine released a gacha collection called Bookworm Nest in March 2014, and the collection had a rare vending machine that dispenses a book of choice. You've got one of those prop books given out from the vending machine.
Since she sold it as a vending machine (dispenser), all contents (book objects) were with copy/trans perms for the next owners to distribute book objects - If the owner and creator of a dispenser were the same person, no need to make the contents copyable.

The book was scripted to go on a toucher's hand when it's touched (and the permission_attach was granted) then be detached without leaving any copies. However, instead of clicking, you (or someone who gave you a copy of the book) took it into the inventory. That's why the book in your inventory now and still disappears each time you wear & take it off.
To avoid such confusion, you may want to add extra lines for making the object anti-rezz.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2540 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

  • Create New...