Sent Inventory on llListen

[2toe Bigboots]

Okay so i want a object to send a notecard when it hears something on llReagonSay

But i dont wanna use UUID, becasue if theres a reasone to rerez or if theres several of these.

I have object say llRegionSay(-111,"Update Request"); to triger the send

But not do i heave object B send with out a UUID ? Also thinking i want it to only send to the one that asks. 

So if i have say 5 object A and only one gets rerezed how would i get the update to the one object ?

[Darkie Minotaur]

Hmm - I'm not sure I'm getting you completele here - let me recap:

There is an object A that shout in a region - upon this shout, object B should send an nc to other objeects, right? Your problem is that you might miss some objects, because the UUIDs have changed, right?

[2toe Bigboots]

Pretty much

I really dont wanna use UUID at all

and if not to complex be able to only send to object hat shouted and not all named the same.

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dark you basicly shown my 80% of what i know of LSL lol someone should pay this guy (if only i had some L$ lol)

[Rolig Loon]

I am not at all sure that I understand your question, but let me gve it a shot.

When you use llGiveInventory, you need to provide a UUID for the object or avatar you are sending the object to.  If you are sending it on request, then the request will be heard in a listen event.  Whenever a listen event is triggered, it tells you where the message came from.  So all you need to write is ...

listen (integer channel, string name, key id, string msg){     if(msg == "Gimme Object B")     {          llGiveInventory(id, "Object B");     }}

 Is that what you were asking?

[Darkie Minotaur]

For sending the nc, you will need a UUID - but if you are sending to the object calling, you have the UUID - it is a parameter of the listen event.

[2toe Bigboots]

Very close, but say i was to add 3 more of these to the sim? i would have to edit the script ?

[Darkie Minotaur]

if you're sending to the calling script, it doesn't matter how many you add - the calling one always can be identified in the way shown above.

[Rolig Loon]

You can't just send items to "the sim."  You have to send then to specific recipients and you need to know their UUIDs.  But if you are only sending Object B when it has been requested, you already know the UUID, so what's the problem?

[Dora Gustafson]

You can use the same name and use the UUID to find out if the request is from an A object that has got an update

1. A request an update
2. B receives request.
   If UUID is unknown then UUID is saved
   B transmit update using llGiveInventory( key UUID, string ...);

[2toe Bigboots]

This is what ive got 

 

default{    state_entry()    {        llListen(-1985,"","","Update Request");    }    listen (integer channel, string name, key id, string msg)     {        if(msg == "Update Reduest")     {          llGiveInventory(id, "userKeys");     }    }}

 

[Rolig Loon]

I don't understand the question.  Any message goes to a "defined channel."  That's why you have a llListen statement in your script.  It defines the channel that the listen event listens to.

[2toe Bigboots]

My bad im not stating my self very well today lol im sorry. I posted a page back what i came up with.

Awsome got it working now. Dark and Rolig you 2 are awsome. Always there to answer me even when its a nubby question (90% of the time lol) 

thank you .

[Rolig Loon]

Congratulations.  Now, to simplify that, you can either remove the "Update Request" filter from the llListen statement, or remove the if (msg == "Update Request") test from the listen event.  You don't need both of them, because they do exactly the same thing.

[Void Singer]

just to clarify, even if there are multiple objects on the region with the same name, each one will have a unique UUID, always

[2toe Bigboots]

Awome i did as you suggested Roli and removed Update Request from llListen. Works good. I figured that it would update every object with same name but nope works jsut as i wanted it.