Communications with a dropped-in script?

[Domitan Redenblack]

I have an object which allows a script to be dropped into it's contents.

Should I use llMessageLinked( ) to talk with it? Or a chat channel?

[Darkie Minotaur]

apart from the fact that I would always prefer linked messages where they are possible - all in all they are way more reliable - if you mean same prim, chat isn't an option since it is not heard.

[Domitan Redenblack]

---

Darkie Minotaur wrote: ...chat isn't an option since it is not heard.

---

Even if the dropped-in script has a Local chat listener, or a channel listener?

[Darkie Minotaur]

a quote from the wki: "A prim cannot hear itself, to prevent problems with recursion. " - you'll find that quote with llSay, llWhisper, llShout, llRegionSay and listen

[Domitan Redenblack]

So if someone drops in a script into the main object contents, how should I talk to it and vice-versa?

I want a third party script to be able to issue commands (on a channel?) to control functions in the main script of the object...

 

[Darkie Minotaur]

where is the problem - in both cases linked message and chat - both scripts would follow certain conventions so they could communicate in a meaninful way. So in both cases you would have to implement some type of 'API'. Another such convetion would be that the scripts use linked messages rather than chat

[Domitan Redenblack]

Darkie, sorry, but I feel very stupid and confused, and now paranoid here.

Your replies seem very vague to my inexperienced mind; I am asking for advice on What experienced scripters would recommend, and how to go about setting up comms with a script which is dropped in by the owner of the object.

 

1. Can I use llMessageLinked if the drop-in script is in the same contents as the main object script? How? Do I need to detect "an addition" to the contents and then search the contents and then set up llMessageLinked( )? Is that a stupid way to do it?

2. Is it easier to chat to the drop-in script on channel -12345 (etc) and have the drop-in chat back on channel -54321 (etc) ? If two diff channels are used for send/receive, I do not see how that could cause recursion...

3. Some other method that newibes (me) would not notice?

 

Thanks

 

[Rolig Loon]

A script cannot listen to chat generated in the same prim.  However, it can listen to chat generated in another prim in the same linkset. 

Like Darkie, I think that llMessageLinked is generally the preferable solution because all communication is internal, requiring no listeners at all.  If you're interested in what's likely to be easiest for a potential user, though, I'd suggest creating a two-prim object.  (Put your own script in a small root prim and leave a BIG, obvious child prim for the other person to drop their script in.  ETA: See below )Then issue one simple rule: 

Your script must contain this line in state_entry:

            gChannel = (integer)("0xF" + llGetSubString(llGetKey(),0,6));

and chat messages must be in the form llWhisper(gChannel, message). 

Then just be sure that your own script contains the same definition of gChannel and has an open listener tuned to it.  That guarantees that your script and the new one will always be communicating on a high negative channel that is unique to the object itself (since it is based on the object's own UUID).  That simple rule is easy for others to follow and minimizes lag issues with chat.

ETA: Anything the user drops in the object will end up in the root prim (d'uh, forgot that), but you can move it as soon as it's dropped in.  Just write:

        llGiveInventory(llGetLinkKey(prim),gThisScript);
        if (~llGetInventoryType(gThisScript))
        {
            llRemoveInventory(gThisScript);
        }


where prim is the number of the child prim (2) and gThisScript is the name of the script someone just dropped in.

[Darkie Minotaur]

1. Yes. I know that you're no big friend of wiki reading - but again, it helps to understand how it would work: llMessageLinked
2. Two points: If the two scripts are in one prim, they won't hear each other anyway - just to avoid recursion . You ca discuss further - but that's the way it is
3. You don't really need more than linked messages

OOne general remark: People can't drop scripts into objects that don't belong to them - the wiki would have told you that as well

[Rolig Loon]

---

Darkie Minotaur wrote:

OOne general remark: People can't drop scripts into objects that don't belong to them -

the wiki

would have told you that as well

---

Oh, yeah.  I forgot that too.  :smileysurprised::smileysad:  So much for a cool solution.

[Domitan Redenblack]

---

Rolig Loon wrote: ...I'd suggest creating a two-prim object.

Your script must contain this line in

state_entry

:

           

gChannel = (integer)("0xF" + llGetSubString(llGetKey(),0,6));

and chat messages must be in the form

llWhisper(gChannel, message)

. 

Then just be sure that your own script contains the same definition of

gChannel

and has an open listener tuned to it.

....

ETA: Anything the user drops in the object will end up in the root prim (d'uh, forgot that), but you can move it as soon as it's dropped in.  Just write:

        llGiveInventory(llGetLinkKey(prim),gThisScript);

        if (~llGetInventoryType(gThisScript))

        {

            llRemoveInventory(gThisScript);

        }



where

prim

is the number of the child prim (2) and

gThisScript

is the name of the script someone just dropped in.

---

Rolig, thanks.

 

1. This is a very cool solution, and yes, only the owner will be dropping stuff into the object. That fixes that problem, correct ?

2. I will need one channel for Root-chatting-to-#2-prim and a different channel for #2-chatting-to-Root-prim, yes? (e.g. gChannel - 1), or does the "can't chat to your own prim" automatically fix this? (I think it does...)

3. I will need a Changed( ) handler to recognize the owner drops the new script in, and then do the script move, correct ? Or is there another way?

 

:matte-motes-sunglasses-1:

 

 

[Darkie Minotaur]

1. This only partially fixes the problem - or better: I leads straight to another problem. If you transfer a script with llGiveInventory, it will get disabled. So you would need another script setting the incoming one to running. I still don't understand why you don't like the much more elegant linked message solution - but well.
2. It does
3. Either a changed or a timer.

[Rolig Loon]

Just remember Darkie's very cogent warning about dropping scripts into objects.  To quote from the LSL wiki:

"Scripts are an exception to what is allowed to be dropped in. If a user without modify permissions to a prim attempts to drop a script into it, the inventory addition is rejected and the prim shouts (sic -- shouts, not says) "Not permitted to edit this!" This is for obvious security reasons. If you own the prim and have mod rights to it, you can drop a script in. Friends who have mod rights to your stuff can also drop scripts in. " 

So, if you are going to use this approach, be sure that you give next owner MOD rights to the object. 

Darkie's got the answers to the three questions you just posed.  I agree with him that the llMessageLinked approach is still the most efficient way to handle things, from the scripter's perspective.  It requires less event handling, is faster, and is a zero lag solution.  From a user's perspective, the solution I proposed may be easier to understand, if only because most novice scripters are more familiar with chat and more likely to screw up an unfamiliar linked message.  I'm really not making a strong argument for it.  I just proposed it so you could see that there is an alternative.

[Domitan Redenblack]

Yes, I am seeing the differences now. This is a very useful discussion for me. Lots of side-effects and gotchas that were unclear when I asked the question *(which is why I asked it this way).

Thanks very much, both of you. Let me look closer at llMessageLinked( ) and see if I have more questions about it.

°͜°

 

[Innula Zenovka]

---

Darkie Minotaur wrote:

1. This only partially fixes the problem - or better: I leads straight to another problem. If you transfer a script with llGiveInventory, it will get disabled. So you would need another script setting the incoming one to running. I still don't understand why you don't like the much more elegant linked message solution - but well.

---

If you transfer the script with llGiveInventory, I think you have either to recompile the script or to take the object back into your inventory and then rez it again.   And in either event, you have then to set the scripts running manually.

The only way to give a running script, to my mind, is with llRemoteLoadScriptPin

[Void Singer]

there is on additional method... llGiveI(nventory to object, the recieving object gets a dead scrip, but if you then move that script to another prim with remoteload it will work.

it doesn't work for seeding scripts into all prim, because you have to set up the pin in advance, but it does work for activating scripts if you've already set up a pin (which is a prim property... though I don't advise leaving it open)