LSL Function request: llCollectObject - Collect rezzed object by UUID

[Cielo Capalini]

I've created a feature request for a new script function that would allow an object to rezzed, modified and collected again.
This would help combat copybotting of gift cards, as well as allow custom items to be sold and help make naming and boxing products faster for creators.

If this is something you feel would be helpful, or if you have any suggestions, please add a comment here https://jira.secondlife.com/browse/BUG-228932

Thank you in advance for any support you can offer in getting this pushed through. ❤️
 

[animats]

31 minutes ago, Cielo Capalini said:

I've created a feature request for a new script function that would allow an object to rezzed, modified and collected again.
This would help combat copybotting of gift cards, as well as allow custom items to be sold and help make naming and boxing products faster for creators.

If this is something you feel would be helpful, or if you have any suggestions, please add a comment here https://jira.secondlife.com/browse/BUG-228932

Thank you in advance for any support you can offer in getting this pushed through. ❤️
 

If you have a script in the rezzed object, you can communicate with it and tell it to call llDie, which will delete the object.

No-copy objects present some extra problems. If you're trying to get no-copy objects back, that's a problem. If it's your object, you can set it as no-copy for next owner, and give it to an object to another prim under different ownership, and let that object rez it as a no-copy object. I think.

Try to describe the use case more clearly and maybe someone can figure out a way to do it.

Also, the proposed solution results in people frantically trying to get the object off the current sim before the  new "llCollect" takes the object out of their hands. Or off their body.

 

[Cielo Capalini]

  

8 minutes ago, animats said:

If you have a script in the rezzed object, you can communicate with it and tell it to call llDie, which will delete the object.

No-copy objects present some extra problems. If you're trying to get no-copy objects back, that's a problem. If it's your object, you can set it as no-copy for next owner, and give it to an object to another prim under different ownership, and let that object rez it as a no-copy object. I think.

Try to describe the use case more clearly and maybe someone can figure out a way to do it.

Also, the proposed solution results in people frantically trying to get the object off the current sim before the  new "llCollect" takes the object out of their hands. Or off their body.

 

 

The desire is not to have the object deleted. It's to be able to modify an object that is created by you, then take it back into the 'vendor' objects inventory.

For gift cards, it would allow a gift card vendor to, upon a purchase being made, rez a gift card, apply a unique code to the end of it, register that code to a vendor system database, then it would be collected again by the vendor and handed to the buyer. That card is now trackable, and upon use, that code can be marked as redeemed. Meaning any other cards, copybotted from that card would be useless.

For creators to sell custom objects, a vendor could have dialogs take custom selections from the buyer, rez an object, apply the relevant custom textures, take it back in and hand it to the buyer.

People wouldn't be frantically trying to get it off the sim, because until it's handed to them, the object wouldn't be owned by them for them to be able to take it.

Edited June 16, 2020 by Cielo Capalini

[Wulfie Reanimator]

I can kind of see some uses for a feature like this, but regarding the "gift card copybotting" thing -- there are already much better methods.

First of all, why couldn't the gift card modify itself the first time the new owner wears it? It would be a simple instruction to them. "You must wear the gift card near the vendor after purchase."

Secondly, if your gift card can be simply copybotted, your design has bigger problems. It means anybody could just make their own gift card even without such a tool. Scripts are the only thing that can't be duplicated, so you should exploit that. The script itself should generate a secret key of some kind and store it internally (and register that in the database if you have one, but databases aren't necessary for gift cards). This way, all gift cards would appear the same but still be able to differentiate.

[Lucia Nightfire]

Instead of "copybotted" I assume they mean one of the many no-copy "duplication" means bad actors have been using for years, particularly with gachas.

Said duplication means include scripts and their current memory states.

Gift cards, vouchers and even some breedables that are sold through a scripted vendor initially exist as an "unregistered/unredeemed" object in the user's inventory which can be boxed/sold/traded.

A server is usually contacted by the scripted vendor upon sale and a yet-to-be-redeemed total is incremented for the item type sold.

It isn't until the item is attached/rezzed where it can communicate with a server for the first time, providing scripts are not off at the region level.

At this point a serial number can be assigned, sometimes also added to the object name.

The problem lies between the time of sale/receiving and the first server communication.

During this time, bad actors can duplicate the item and either redeem the copy them self or sell the copy to someone else who redeems it and as long as the yet-to-be-redeemed total for that item type is not 0, the related server should offer whatever service/object is affiliated with that item type.

If we had a way for an object to register itself prior to the vendor selling/giving it to a buyer, it would make it harder for bad actors to sell duplicates.

There would still need to be a way for potential buyers/traders to check serial numbers with a server/vendor to verify if an item has been claimed or not.

This would be aided by the method of including the serial number in the item's name so it can be seen in the inventory of a reseller's vendor object or in the contents section of a Marketplace listing.

I think an AllowAgentToBuy() & PERMISSION_SELL_OBJECT method which allows only a certain agent to buy an object rezzed by the vendor would be more feasible, though.

Said function would have inputs such as Price & Copy, Content, Original mirroring what can be set on a object via a user's viewer.

Edited June 16, 2020 by Lucia Nightfire

[Cielo Capalini]

I posted this on the ticket too:

I have received feedback in regards to concerns this would only aid copybotters. Because it would allow items to be taken in before a lldie command. I'm not 100% clear on how that would help, they would still only have that copy and it would still try to activate lldie the next time it was rezzed.

I did specify that the owner of the rezzed object would need to be the same as the vendor doing the 'collecting', for extra security though, it could be that both the owner and creator need to be the same as the vendor. This way, once the object leaves the creators hands, it can't be picked up by someone else's vendor.

9 hours ago, Wulfie Reanimator said:

First of all, why couldn't the gift card modify itself the first time the new owner wears it? It would be a simple instruction to them. "You must wear the gift card near the vendor after purchase."

This is one of the current ways of gift cards working, there is still ways around it, as Lucia has mentioned. Also, it's an extra step for customers, many of whom might not see the instructions, just buy a card and be on their way. This would be a more elegant solution.

I love your suggestion too Lucia, an AllowAgentToBuy function would be great. I've often wondered why it didn't exist like being able to sell land to a specific avatar.

There is other uses though, for example, it would mean scripts to retexture, name and package products for creators would be possible, saving a bunch of time. At the moment only the retexturing and naming part is possible, but creators still need to pick up the items one at a a time to put them in their applicable boxes. For clothing creators who have 20+ colors and 3+ body types, this is time consuming and tedious.

[Twisted Pharaoh]

llDie does not guarantee that the item will be deleted because it can be taken to a no-script area.

 

[Cielo Capalini]

1 hour ago, Twisted Pharaoh said:

llDie does not guarantee that the item will be deleted because it can be taken to a no-script area.

 

I'm aware of that. That could be done even without this proposed function though.

The reason for this function is in no way related to objects using llDie. It's to be able to modify objects towards a purpose, then collect them again.

I received feedback via dm as well that it would allow to "pick stuff up before a script runs llDie() and gives more opportunities to copybot".  If the object is collected, the actual object, not a copy of it, then they would have no more copies than they started with.

[Cielo Capalini]

So, to make it a little clearer, because there seems to be confusion. Here is how it is proposed to work:

Creator has a 'vendor' with an object inside it.
The 'vendor' has a script for rezzing the object and running llCollectObject.
The object has a script to ping it's UUID to the 'vendor', as well as any modification commands.
When clicked, or a purchase is made, the 'vendor' rezzes a copy of the object.
The object applies it's modifications, including changing it's name to be unique to the one inside the 'vendor'.
The object then pings the 'vendor' it's UUID.
The vendor receives the UUID and uses it to run llCollectObject.
The object is derezzed from the sim and placed in the inventory of the 'vendor', just like how you take an object from a sim into your own inventory.

It is not taking a copy, it is taking the actual object that is now modified. In the case of gift cards and custom items, it can now be passed to a buyer.
 

Added on to the comments in the jira is a further security proposal:
A 2 part function, in which there needs to be a 'code' in a hook type function in the rezzed object script. So the 'vendor' object would need to call it in with a matching code. Like llCollectObject(key, 'code') and llBeCollected('code'). So unless you know the code specified in an object you couldn't collect it.

Along with the function only being able to be used where the vendor and the object have the same owner, this would make it very secure.

[Mollymews]

in terms of automating pick up isn't this already achieved with llReturnObjectsByID

parent rezzes a template object. Template object changes its attributes determined by parent. Updated (template) object informs parent of its uuid.  Parent returns the updated object to owners inventory. Owner drags updated object to vendor

 

[Wulfie Reanimator]

1 hour ago, Mollymews said:

in terms of automating pick up isn't this already achieved with llReturnObjectsByID

parent rezzes a template object. Template object changes its attributes determined by parent. Updated (template) object informs parent of its uuid.  Parent returns the updated object to owners inventory. Owner drags updated object to vendor

That's very much not the same thing because that requires user-intervention from the owner.

The core idea behind this suggestion is to have standalone products that can rez-and-take independently.

Edit: By the way, an object that rezzes another object will always have the UUID of the object that was rezzed. The object_rez event has it, so no communication from the rezzed object is needed.

Edited June 16, 2020 by Wulfie Reanimator

[Mollymews]

i probably need to play with this inworld

another question tho. When the person touches the rezzer, could the object be rezzed and updated then llAttachToAvatar ?

[Cielo Capalini]

9 minutes ago, Mollymews said:

i probably need to play with this inworld

another question tho. When the person touches the rezzer, could the object be rezzed and updated then llAttachToAvatar ?

It could, but it would require the buyer to give perms to do so, which would likely freak a lot of customers out when buying something, given the many scam objects people are being warned about in recent times.

It also would only apply to the use cases where an item needs to be passed after the modification, not where it is for automating tedious tasks like with packaging items.

Edited June 16, 2020 by Cielo Capalini

[Wulfie Reanimator]

5 minutes ago, Cielo Capalini said:

It could, but it would require the buyer to give perms to do so, which would likely freak a lot of customers out when buying something.

But llAttachToAvatar wouldn't give the object to them, isn't that the end-goal?

You can only use that function to attach to the owner's avatar, which would be the seller, not the customer.

[Cielo Capalini]

1 minute ago, Wulfie Reanimator said:

But llAttachToAvatar wouldn't give the object to them, isn't that the end-goal?

You can only use that function to attach to the owner's avatar, which would be the seller, not the customer.

Oh, I thought it did. That once they detach it, it's still in their inventory. I guess not then.

[Wulfie Reanimator]

10 hours ago, Cielo Capalini said:

Oh, I thought it did. That once they detach it, it's still in their inventory. I guess not then.

It does stay in inventory when detached... but it can't be attached to anyone other than the owner.

llAttachToAvatarTemp can attach to other, non-owner avatars, but with that function the object is never given to their inventory.

http://wiki.secondlife.com/wiki/LlAttachToAvatar

http://wiki.secondlife.com/wiki/LlAttachToAvatarTemp

Edited June 17, 2020 by Wulfie Reanimator

[Cielo Capalini]

1 minute ago, Wulfie Reanimator said:

It does stay in inventory when detached... but it can't be attached to anyone other than the owner.

llTempAttachAvatar can attach to other, non-owner avatars, but with that function the object is never given to their inventory.

Ahh, makes sense. Thanks for the clarification Wulfie! I haven't done anything with attachment scripts yet, but I may in future, so that's real handy to know.

[Lucia Nightfire]

llAttachToAvatarTemp() can transfer ownership, but then it exists in "temp attachment" state where it can never go to your inventory, unless it fails to attach.

Attempting to use llAttachToAvatar() with someone else's permissions will result in a "Script trying to attach to someone other than owner!" script error.

[Qie Niangao]

No doubt this is impractical at least for this purpose because (among other constraints) there are two requests for permission to attach (assuming Experience permissions aren't an option), but it illustrates a temp-attached object that transfers to the recipient's ownership, and then rezzes another object that customizes itself and then attaches and finally detaches to get into the recipient's Inventory.

Because that final object must be rezzed by script owned by the recipient, its next-owner permissions must include Copy, and the recipient must be able to rez on the site.

Anyway, to exercise the demo:

1. rez an object,
2. set the object for next-owner Copy
3. drop in the script below
4. set the script for next-owner Copy
5. take a copy of the scripted object into Inventory
6. embed that copy inside the rezzed object
7. take a copy of that object-embedded object into inventory
8. in the rezzed object, replace its contents with the object-embedded copy from step 7
9. get an alt to test by touching the rezzed object

// Three scripts mashed into three states, illustrating attachment from a temp-attached object
// At least the final, "real" attachment must be copy-perm for next owner, so it can be rezzed from the temp attachment
// (and if it's not phantom, might bump you around a bit)

integer basicRezzerChannel; // used both ways
key toucherKey;
integer listenHandle;

default // just a basic touch rezzer for demo purposes
{
    on_rez(integer start_param)
    {
        if (0 == start_param)   // rezzed from inventory (or something dumb)
            return;
        if (1 == start_param)   // rezzed by temp-attached version so we're owned by the right guy
            state realAttachment;
        else    // rezzed by basicRezzer
            state tempAttachment;
    }
    touch_start(integer num_detected)
    {
        toucherKey = llDetectedKey(0);
        basicRezzerChannel = -1000000000 - (integer)llFrand(1000000000.0);
        llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos(), ZERO_VECTOR, ZERO_ROTATION, basicRezzerChannel);
    }
    object_rez(key id)
    {
        llListenRemove(listenHandle);
        listenHandle = llListen(basicRezzerChannel, "", id, "");   // handshake: wait till it says it's listening
    }
    listen(integer chan, string name, key id, string text)
    {
        llRegionSayTo(id, basicRezzerChannel, (string)toucherKey);
    }
}

state tempAttachment
{
    state_entry()
    {
        // listen to our rezzer for message identifying to whom we should attach
        key ourRezzer = llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]), 0);
        integer rezzerChan = llGetStartParameter();
        llListen(rezzerChan, "", ourRezzer, "");
        llRegionSayTo(ourRezzer, rezzerChan, "(ready and listening)");
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_TEMP_ON_REZ, TRUE]);  // tidy in case perms denied
    }
    listen(integer chan, string name, key id, string text)
    {
        llRequestPermissions((key)text, PERMISSION_ATTACH); // transfer ownership if perms granted
    }
    run_time_permissions(integer perms)
    {
        if (PERMISSION_ATTACH & perms)
            if (llGetAttached())
                llDetachFromAvatar();
            else
                llAttachToAvatarTemp(0);
    }
    attach(key av)
    {
        if (av)
        {
            llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos(), ZERO_VECTOR, ZERO_ROTATION, 1);
            llRequestPermissions(av, PERMISSION_ATTACH);    // need to get perms AGAIN for transfered temp-attachment
        }
    }
}

state realAttachment
{
    state_entry()
    {
        llWhisper(0, "Customize ourself and attach for real...");
        llSetObjectName("Customized "+llGetTimestamp());    // Trivial customization for demo
        llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_TEMP_ON_REZ, TRUE]);  // tidy in case perms denied
    }
    run_time_permissions(integer perms)
    {
        if (PERMISSION_ATTACH & perms)
            llAttachToAvatar(0);
    }
    attach(key av)
    {
        if (av)
        {
            llWhisper(0, "and then detach to inventory");
            llDetachFromAvatar();
        }
    }
}

 

[Cielo Capalini]

The object would be modified prior to the initial attaching, no double attach needed. At any rate, as Lucia pointed out, it would throw an error in regards to the perms. That's on top of it not being  a suitable replacement for the intentions of the function for all use cases.