Deliver object using UUID key

[Moreira Ballinger]

 

Hello everyone! I would like to know if there is a script that allows the sending of an object by means of a UUID key?

 

As with images, where you can change the color of a prim using only the key of an image, even without having it in your inventory. So, I would like to know if I can create a prim, take the key from it and put it on a prim server. When the person clicks on this prim, the server will send a non-copy object to the person, from the prim key, and not from the server's inventory.

 

Please follow the logic:

 

1 ° I have a soup pot and I want to put it in my RPG tavern. She will be a food server. But I don't want to put the soup bowl in it, because it needs to be a copy to always be sent. If the bowl goes to the inventory of the clicker, it will never disappear from there, because it is in status copy.

 

2 ° I want the person to click on the pan, receive a bowl of soup not copy. The bowl needs to disappear from the inventory of the person who received it when they rezz in the world. Thus, the person will always be shopping at the tavern.

 

Did you understand?

I need my pot to always have soups, to send to the avatars that click, but I need the soup to arrive in the person's inventory in non-copy mode. There will be a communication script in the soup, which will communicate with Hud and satisfy the avatar's hunger. If anyone knows if this is possible, or has any different ideas for the problem I posted, please help me!

I appreciate it!

Edited March 4, 2020 by Moreira Ballinger

[Rachel1206]

The most elegant solution would be to use attachment to an avatar temporarily using llAttachToAvatarTemp

No worries about inventory of person and weird temp rezzer.

You need to understand the basics of llRequestPermissions and the basics to handle ( llDie ) the objects given, if the person by some reason does not attach/accept attachment.

 

[Wulfie Reanimator]

You cannot send objects by UUID.

Rachel is correct. The soup pot should rez a new bowl and the bowl should use llAttachToAvatarTemp to temporarily attach itself to an avatar's hand. The avatar will not get the bowl, they can only detach it which will make it disappear.

[Moreira Ballinger]

9 hours ago, Rachel1206 said:

The most elegant solution would be to use attachment to an avatar temporarily using llAttachToAvatarTemp

No worries about inventory of person and weird temp rezzer.

You need to understand the basics of llRequestPermissions and the basics to handle ( llDie ) the objects given, if the person by some reason does not attach/accept attachment.

 

Thank you for your comment.

My beer keg works like this, it provides a beer mug, with llAttachToAvatarTemp 
script. But unfortunately, this type of action does not work very well 
with tray, dishes and bowls, because they need to be placed in 
the world, except fruits, breads and other foods that can be 
consumed by hand. Dishes and bowls are awkwardly attached to 
the hand and lose their realism. I am looking for a solution to 
stop food from being functional in the avatar inventory so that 
there is a real need for food.

Edited March 4, 2020 by Moreira Ballinger

[Moreira Ballinger]

8 hours ago, Wulfie Reanimator said:

You cannot send objects by UUID.

Rachel is correct. The soup pot should rez a new bowl and the bowl should use llAttachToAvatarTemp to temporarily attach itself to an avatar's hand. The avatar will not get the bowl, they can only detach it which will make it disappear.

Thanks Wulfie!

 

I already use this system in beer kegs and in fruit and bread baskets, but with food plates and bowls too, I wish there was a way to deliver an item in the copy, or, at least the item would disappear from the inventory, or cease to be functional after a while, to create the need to realistically satisfy hunger.

 

Edited March 4, 2020 by Moreira Ballinger

[Fenix Eldritch]

Would the next-owner permissions apply here? If you create an object and uncheck the next-owner-copy permission in the build tool, would that make the item no-copy only as it is transferred to the new owner via llGiveInventory? I haven't used that much so I don't know off the top of my head, but glancing over the next owner permissions test page makes me think it might be an option?

Edited March 4, 2020 by Fenix Eldritch

[Rachel1206]

8 hours ago, Moreira Ballinger said:

Thank you for your comment.

My beer keg works like this, it provides a beer mug, with llAttachToAvatarTemp 
script. But unfortunately, this type of action does not work very well 
with tray, dishes and bowls, because they need to be placed in 
the world...

OK, the only solution I can think of is to rezz the items at fixed places and use a timer to let the item die after a given time or if the person leaves the area.

[Mollymews]

9 hours ago, Moreira Ballinger said:

I already use this system in beer kegs and in fruit and bread baskets, but with food plates and bowls too, I wish there was a way to deliver an item in the copy, or, at least the item would disappear from the inventory, or cease to be functional after a while, to create the need to realistically satisfy hunger.

normally with objects which can be taken into Inventory then we can start a time clock on first rez.  When the time runs out (on first or subsequent rezzes) then we llDie the object

if we want to make the Soup No-Mod No-Copy and No-Transfer then two linked prims. Stick the script in the linked prim (not the root prim), Set script to No-Mod No-Copy.  Set the object to No-Mod, No-Transfer

 

[Kyrah Abattoir]

Assets that can be invoked by UUID:

• Textures
• Notecards
• Sounds

Assets that can be TRANSFERED by UUID.

• None.

You'll have to use llAttachToAvatarTemp() And if the "device" is going to be sold, the buyer need to rezzable objects copy & transfer, there is no way around that.

[Innula Zenovka]

If I properly understand the problem, you want to make an item, a soup-bowl dispenser -- that contains soup bowls that are copyable for the owner of the dispenser, so the tavern-owner can sell as many bowls of soup as her customers want to buy, but which aren't copyable by the customer at the tavern.  

The soup dispenser contains unlimited bowls of soup, but each bowl can be used only once.

Since the SL permissions system doesn't have an option for "copyable by next owner only," which is unfortunate, since it would simplify life a lot, there seem to me to be two workarounds.

First, you could have the soup-bowl-dispenser communicate with a remote server that belongs to you and delivers the bowls of soup to the customer's inventory, on the same lines as an affiliate vendor.    You own a server somewhere, which contains soup bowls belonging to you, set to no copy, which receives messages, whether by http_in or via llEmail, telling it to deliver bowls of soup direct to the customer.

The other option might be to make your soup-bowl dispenser part of a large piece, or part of a set of bar furniture, whereby the customer sits at the table, touches the soup tureen (the dispenser) and this rezzes a bowl of soup in front of the customer (or otherwise causes it to appear) and then deletes (or makes vanish) the bowl after the end of the session.    Quite how you do that depends on the set-up, but it's a technique I've used in the past with some success. 

[Moreira Ballinger]

10 hours ago, Innula Zenovka said:

If I properly understand the problem, you want to make an item, a soup-bowl dispenser -- that contains soup bowls that are copyable for the owner of the dispenser, so the tavern-owner can sell as many bowls of soup as her customers want to buy, but which aren't copyable by the customer at the tavern.  

The soup dispenser contains unlimited bowls of soup, but each bowl can be used only once.

Since the SL permissions system doesn't have an option for "copyable by next owner only," which is unfortunate, since it would simplify life a lot, there seem to me to be two workarounds.

First, you could have the soup-bowl-dispenser communicate with a remote server that belongs to you and delivers the bowls of soup to the customer's inventory, on the same lines as an affiliate vendor.    You own a server somewhere, which contains soup bowls belonging to you, set to no copy, which receives messages, whether by http_in or via llEmail, telling it to deliver bowls of soup direct to the customer.

The other option might be to make your soup-bowl dispenser part of a large piece, or part of a set of bar furniture, whereby the customer sits at the table, touches the soup tureen (the dispenser) and this rezzes a bowl of soup in front of the customer (or otherwise causes it to appear) and then deletes (or makes vanish) the bowl after the end of the session.    Quite how you do that depends on the set-up, but it's a technique I've used in the past with some success. 

 

Hello Innula Zenovka! Thank you for your comment. The only server I own is the market place store, which despite having no items, is active. Does it serve as a remote server?

[Innula Zenovka]

19 minutes ago, Moreira Ballinger said:

 

Hello Innula Zenovka! Thank you for your comment. The only server I own is the market place store, which despite having no items, is active. Does it serve as a remote server?

No, you'd need to have some land somewhere, and keep a remote delivery server there.    It would work in the same way remote vendors do, or updaters that automatically send you updated products when you log in.

So long as you own some land, so you can be sure that you can rez a server prim there, and it won't ever be removed or re-rezzed (because its uuid can't change) then it's comparatively straightforward to script.   If that's not the case, then things get a bit more tricky but it's certainly doable.

It may be that there's a commercial product you could use -- it's the same principle as updaters, after all, and I'm sure someone must sell those as a diy kit.

[Moreira Ballinger]

35 minutes ago, Innula Zenovka said:

No, you'd need to have some land somewhere, and keep a remote delivery server there.    It would work in the same way remote vendors do, or updaters that automatically send you updated products when you log in.

So long as you own some land, so you can be sure that you can rez a server prim there, and it won't ever be removed or re-rezzed (because its uuid can't change) then it's comparatively straightforward to script.   If that's not the case, then things get a bit more tricky but it's certainly doable.

It may be that there's a commercial product you could use -- it's the same principle as updaters, after all, and I'm sure someone must sell those as a diy kit.

 

I understand, it would work like those affiliated Vendors.... I'm not very good at programming, but I think if I get a card from this full perm, I might be able to edit it. Thank you very much, you have broadened my view.

[Kyrah Abattoir]

14 hours ago, Innula Zenovka said:

No, you'd need to have some land somewhere, and keep a remote delivery server there.    It would work in the same way remote vendors do, or updaters that automatically send you updated products when you log in.

So long as you own some land, so you can be sure that you can rez a server prim there, and it won't ever be removed or re-rezzed (because its uuid can't change) then it's comparatively straightforward to script.   If that's not the case, then things get a bit more tricky but it's certainly doable.

It may be that there's a commercial product you could use -- it's the same principle as updaters, after all, and I'm sure someone must sell those as a diy kit.

I see several issues with this:

1. It's a brittle solution that means your product will more or less live or die with your store. (EDIT, this should really be made clear on purchase)
2. You will need some sort of external server to relay requests, that means a monthly/yearly running cost.

If your problem is the uncontrolled duplication of soup bowls, if they are temporary attachments, first, the person doesn't get to keep it as it will be destroyed once detached o when they relog. And even if they could, you can simply have the pot initialize the bowls as they are created, and simply make the script non-functional until it has been initialized.

Edited March 9, 2020 by Kyrah Abattoir

[Innula Zenovka]

21 minutes ago, Kyrah Abattoir said:

I see several issues with this:

1. It's a brittle solution that means your product will more or less live or die with your store.
2. You will need some sort of external server to relay requests, that means a monthly/yearly running cost.

If your problem is the uncontrolled duplication of soup bowls, if they are temporary attachments, first, the person doesn't get to keep it as it will be destroyed once detached o when they relog. And even if they could, you can simply have the pot initialize the bowls as they are created, and simply make the script non-functional until it has been initialized.

I agree, but I thought the OP doesn't want to use temporary attachments.   

While I'm not sure I understand quite what the OP has in mind, if I were making something like this for RP purposes, I'd be thinking in terms of a whole tavern table or something, with the soup pot on top of it, and people can sit down it have it rez a bowl of soup in front of them, but that doesn't seem to work for the OP either.