"Building" objects as they come out of a vendor using llRemoteLoadScriptPin and stuff

Hello all,

One of my silly projects I have is a "Christmas Wrapper Machine" which is basically a vendor that puts the desired object inside a package with the christmas wrapper of your choice (instead of a "default" box).

So basically the vendor object will have two types of objects inside: the ones for sale (say, listed in a notecard as usually - there are so many good vendor scripts around, there is no need for me to write my own one from scratch - AGAIN [since I have done one some months ago before adapting one of the freebies lol]), and the "wrapped boxes" (which, for the sake of arguments, let's assume they are a bit more complex than simple texture changes).

The vendor, beyond the usual next/prev buttons and a display, will also have, say, 4 buttons to select the "wrappers". Let's assume we have a "current wrapper" selected, and someone buys one set of clothes.

What I want to give them is one "wrapped box" and put inside that that set of clothes, and finally this wrapped box goes into the buyer's inventory.

My first approach (not tested) would be to rez the correct box outside the vendor, set it to accept inventory, send to it the clothes, and have the buyer pick it from the ground. But I would like to have it sent immediately to the buyer. What I next thought was to send it a small script that is activated remotely with llRemoteLoadScriptPin and that "gives itself".

Alas, the LSL Wiki is clear on this point:



and refers to this 6-month old thread where people asked for the feature of self-giving objects.

I have thought of other ways to give the object away while at the same time pass parameters to it - say, through the object's description, for instance. But I can't affect the object's name or description when it is NOT rezzed (and after giving it away, it's too late).

One way would be to have a two-step process, rezzing a "temporary vendor" object with some information on the proper wrapping to select, and encode this information either in the object's description or a notecard inside, and give the object to the buyer, and llDie() afterwards. When the buyer rezzes the object, it will read the information and apply all changes/transformations to itself (ie. getting textures via their keys, or, if the wrapper is more complex, rez in the necessary prims).

Anybody has a better solution to this crazy problem?

Sortof skim-read, so might have missed something but... yeah llGiveMyself is a Wanted Feature and not soon on the list AFAIK.

Your solutions look great, given the limitations in place.

Azelda

would do bad things.

llSetObjectName((string)++a);
llGiveMyself(llGetKey());

*devil emote*

we need more emotes

you could make wicked fractals out of very basic scripts with llGiveMyself.

I fully support this function.

can't you basically make an object give itself by selling it as an original for L$0?

Hello Zuzi,



You can't even make an object set its own price, so I don't understand how this would work...

Actually, I would love to have llGetPrice() and llSetPrice(). Awww, the automatic vendor industry would bloom

I had to deal with this issue for a lotto vendor. Each ticket had to be unique, but there's no way to do that without rezing it first. For your issue of items in boxes, you COULD just make every possible combination or box and item and store them in the vendor. (I'd put all items in one box type per prim, one for each box type, myself.) That's a lot of set up work, but it makes the actually buying and selling the cleanest.

As I said for the tickets, I couldn't go that route at all. The rezed tickets are set Buy Original with a timer checking to see if their ownership has changed. (Since there's no event for this. [1]) Then when it does, the ticket moves to where it can't be seen to complete its initialization, then it moves to the pick-up spot on the vendor. You can use the GiveInventory command to do this.

So Rez the box inside your vendor where it can't be see (and taken too soon), give it the purchased obejct, then move it out to be taken. You will have to deal with people NOT taking what they bought, since most players are used to getting the item intheir inventory. The second step of taking it is rather clumsy. What we need is a way for a script to return the obejct to its owner's inventory. [2] (That functionality is needed for many things.)


So Feature Requests:

[1] "changed" event for ownership
[2] llReturnToOwner()

Hmm, ok, I get the point... especially after reading the other thread on llGiveMyself()... so this means having to tackle it in another way. Grrr. Actually, I had another application for it. I have a cigarette vending machine, which spews out randomly one of 8 differently textured cigarette packs. So far, what I've been doing is putting the 8 different packs inside the vending machine, and let it pick one randomly However, I have more cigarette pack textures, and it's a pain to update all vendors with them...

In this particular case, there is an easy way out: the script inside the pack of cigarettes can grab a texture by key, and apply it to the pack when rezzed the first time so it's very easy to do. Perhaps this is the easiest way to deal with my original question: give the buyer an untextured box, and let the script inside pick up a texture randomly.

Any other way to do a llGiveInventory() passing parameters to it...? Is there a way to do it across sims? I also imagined another way, which is to send an email to the object, telling it to get texture #3 or something like that. When the object is rezzed the first time, it receives the email, and proceeds accordingly. Actually this is not so easy to do, since before you llGiveInventory(), you don't have the slightest idea of the objects' UUID. So in reality you need to send an email from the object to the vendor, and the vendor will have to reply to that email telling that it should use texture #3 (sending it the key for texture #3), and finally you have to get that texture from "somewhere"... uggh.

Another silly question for you LSL gurus: besides textures, can I get a copy of an object which is "somewhere" on another sim, if I know its key? (assuming I have the proper permissions). Also, do keys change when inside inventory and outside? (I have read a comment somewhere - I think it was on the Wiki - that this key change is possible... but can't remember where I read it...)

Another thing on my wish list: a cleaner way to do inter-object communication across sims without using emails llSendObjectMessage(key object_uuid, string message) and an event like object_message(key origin, string message) would work nicely

A Feature Request thread along these lines.