2 scripts inside inventory

[littlepinkpie]

Hi,

I have 2 scripts inside an object.

Im trying to send a command from script 1 to script 2 using listen, is this correct?

I think it should work but script 2 does nothing, not even listening.

Is there any other way to do this?

Thank you.

[steph Arnott]

Usa a link message, objects can not lhear or chat to them self. ADDED clarity "or chat"

[littlepinkpie]

Thank you so much.

[Rolig Loon]

Nope, that's not going to work.  As the wiki tells you, "A prim cannot hear/listen to chat it generates. It can, however, hear a linked prim."  The only exception is that a script can hear messages generated by its own llDialog or llTextBox activity.

So, you have a few other ways to do what you want.  The simpest is to combine your two scripts into one, so that there's no messaging necessary at all. That's almost always the best idea, because it saves on your total script load and usually means that you need less complicated logic.  If that's not practical, you can send link messages between them instead (using llMessageLinked in one script and a link_message event in the other).  Of you can put the scripts in separate prims and then either send link messages or plain old chat between them.

 

[steph Arnott]

"The only exception is that a script can hear messages generated by its own llDialog or llTextBox activity." that is incorrect, the dialog box communicatition is not object internal, it is veiwer communication

[littlepinkpie]

Even I got the answer from steph, thank you for your contribution!

[Rolig Loon]

That makes no difference, Steph.  The point is that the script can hear messages that are generated by a llDialog or a llTextBox command in the same script, but it cannot hear a message generated by llSay, llShout, llWhisper, etc.  :smileywink:

[steph Arnott]

Sorry but that is incorrect, except for being able to use negative channels, it is no different than if you used the chat field to talk. The spherical 20 metre dia is broad cast is the same a saying /10 on.. It is entirely veiwer communication, a object con not under any circumstance hear or talk to it self.

[Rolig Loon]

Nonsense, Steph.  You know better than that. :smileywink:

 

default{    state_entry()    {        llListen (-1234,"","","");    }    touch_start(integer num)    {        llDialog(llDetectedKey(0)," \n Go ahead, click a button to send a message.", ["Hi, Steph.","I hear you."],-1234);    }    listen (integer channel, string name, key id, string message)    {        llSay(0,"\n I just heard you say , \"" + message + "\"");    }}

One script.  It sends a message on channel -1234 and it hears it in the same script.

[steph Arnott]

no it sends the message to the veiwer and back.llDialog is a vewer chat field, that all.

[Rolig Loon]

And this does not work...

default{    state_entry()    {        llListen (-1234,"","","");    }    touch_start(integer num)    {        llSay(-1234,"Hello, Steph");    }    listen (integer channel, string name, key id, string message)    {        llSay(0, message);    }}

This script is sending a message on the channel -1234 but it cannot hear it. 

We are not concerned about whether YOU can hear the message, Steph. We are only concerned about whether a message generated in the script and sent to an open listen handler can be heard in a listen event in the same script.  Normally, the answer is No.  However, if the message is sent by a llDialog or llTextBox statement instead of llSay, llShout, llWhisper, llRegionSay, or llRegionSayTo, it can indeed be heard by the same script.  We do it all the time.

 

[steph Arnott]

I can only gather we are at odds, which as it you i find uncomfatble about.

If the object is on  0 channel and the trigger is "on" assuming the listen event is open then it will trigger. whrn you type "on"

A dialog box is a pre defined message sender, so dialog box comes up, button says "on",it transmits "on" and  it triggers.

Thats all a dialog box is, a predefined message sender, which btw is the reason "ignore" does no work, becouse it transmits nothing.

[Rolig Loon]

OK.  :smileytongue:  Not "at odds".  Just somehow not understanding each other.  I will try one one time and then I stop because I am getting tired.  Study the first script that I posted ...

default{    state_entry()    {        llListen (-1234,"","","");    }    touch_start(integer num)    {        llDialog(llDetectedKey(0)," \n Go ahead, click a button to send a message.", ["Hi, Steph.","I hear you."],-1234);    }    listen (integer channel, string name, key id, string message)    {        llSay(0,"\n I just heard you say , \"" + message + "\"");    }}

and then answer the following questions:

1. How many scripts do you see here?

2. Where is a message being generated?

3. Is the llListen statement in the state_entry event necessary? What is it there for?

4. Where is the message being handled? Could it be processed if the variable, channel was not defined?

Now, study the second script that I posted and answer the same questions, plus one more ...

5. Why does the first script work, but the second one does not?

=========

In both cases, a message is being generated in a touch_start event one script and is being sent on a channel that has been opened for listening with a llListen statement, and there is a listen event that is prepared to receive messages on that channel. The channel is a critical element in both scripts.  Without it, there is no defined pathway for the script to send a message along, and there is no way for the script to know how to receive messages. The first script uses llDialog, but the second one uses llSay.  That's the only difference between them. The first script works because LSL allows a script to listen to its own messages generated by llDialog.   The second one fails because LSL does not allow a script to listen to its own llSay messages.

Now, I suspect that you will point out another difference:  The message that the first script sends can only be heard by the script that generated it. I cannot hear it with another script, even if that other script has a llListen(-1234,"","","") statement in it. That's fine, and I agree.  But that's just the mirror image of what I have been saying: a message sent with llSay can only be heard by another script or avatar. The first script does hear the message sent by llDialog. The second one does not.

[steph Arnott]

One

By the script

In the script, which generates a chat field on th screen

To recieve the message from the chat field

The chat bax, or menu drop drop down box is preset to the channel defined by the script.

That becouse when the chat box is presented it locks to a response to the chat box

Will reread the first later as am tierd.

[steph Arnott]

Any how have a good sleep, i need it.

We can talk about this another day, maybee in six months. Be blessed.

[Innula Zenovka]

I see what steph is saying, though, Rolig and I think I agree with her.

I think thatt when a script sends an llDialog message, it sends the message to the avatar's viewer, and the viewer knows to reply on the same channel.

It becomes clearer if you change the script slightly:

 

integer iHandle;key kToucher;default{    state_entry()    {        llSetObjectName("llDialog Test");    }    touch_start(integer num)    {        kToucher = llDetectedKey(0);        llListenRemove(iHandle);        iHandle = llListen(-1234,"",kToucher,"");        llDialog(kToucher," \n Go ahead, click a button to send a message.", ["Hi, Steph.","I hear you."],-1234);    }    listen (integer channel, string name, key id, string message)    {        llListenRemove(iHandle);        llSay(0,"\n I just heard "+name+" say , \"" + message + "\"");    }}

The message must come from kToucher, or the script wouldn't be able to hear it, since it's listening only to kToucher.    And, sure enough, it hears the message as coming from kToucher.

You can confirm this by putting a second script in an object nearby:

default{    state_entry()    {        llSetObjectName("Eavesdropper");        llListen (-1234,"","","");    }    listen (integer channel, string name, key id, string message)    {        llSay(0,"\n I just overheard "+name+" say , \"" + message + "\"");    }}

The Eavesdropper also hears the message as coming from the avatar, not the llDialogTest object.  Or am I missing the point?

 

[Rolig Loon]

Yes, I agree with that, Innula. Perhaps the point is nothing more than a semantic one, but the fact remains that the message that is received in the script's listen event was generated in the script's own touch_start event by the llDialog statement. The llDialog and llTextBox functions are special in that way. You cannot do the same trick by sending a llSay message from the script's touch_start event.  The listen event will not receive it, regardless of the fact that a valid channel has been opened with llListen. 

My attention is on listening and on where the message was generated. No action other than a llDialog or a llTextBox will create a message that can be heard by a listen event in the same script, but those two functions will do it. Hence, it is true to say, as the wiki does, that 

A prim cannot hear/listen to chat it generates. It can, however, hear a linked prim.

• Chat indirectly generated (as a result of llDialog, llTextBox or from a linked prim) can be heard if in range.

Whoever wrote that second sentence (Strife?) was quite clever to put it in the passive voice and to add that word "indirectly". I maintain that it makes no difference whether the act of transmission is "direct" or "indirect", which I see to be the crux of what you are saying. The important point is that the act of hearing/listening occurs, and that it is in the same script.

[Innula Zenovka]

I think it is probably just a semantic point but, at least to my mind, "generated" is a misleading term to use.

If you think of the example, 

integer iChan = -1234;integer iHandle;key kToucher;default{	state_entry()	{		llSetObjectName("TextBox test");	}	touch_start(integer total_number)	{		llListenRemove(iHandle);		kToucher = llDetectedKey(0);		iHandle = llListen(iChan, "", kToucher, "");		llTextBox(kToucher, "Please enter your message and click \"Submit\"",iChan);	}	listen(integer channel, string name, key id, string message)	{		llListenRemove(iHandle);		llSay(0,name +" just said "+message);	}}

I'd say that the script no more "generates" the message it hears and repeats than does an answerphone when it says "Please leave a message after the tone."    The script prompts you for a message, and then repeats whatever message you give it.

 

[Rolig Loon]

Well put. The English language gives us many possible words for situations like this, but it's hard to find one that gets at the nuances we are discussing.  I agree that "generate" doesn't quite capture it.  "Initiate" doesn't either, although maybe it comes closer.  The problem is that a llDialog or llTextBox command requires the independent action of a person.  A script can't send the message unless a human does the touching that "generates/initiates/creates/produces" it. A script is quite capable of sending a llSay message by itself, however.  

So our semantic distinction seems to come down to which end of the process we choose to emphasize: (1) who "sends" the message or (2) who receives it.  In the end, it doesn't truly make a difference as long as we are clear that a script can hear a message that somehow or other involves whatever it is that a llDialog or llTextBox in the same script can do, but it can't hear what a llSay in that script does.

[steph Arnott]

I did a test, if the channel is set to zero and one types the button "option" in normal chat then the script invokes that choice.Tho as far as im aware that goes to the degug channel. Any how, nothing worth stressing about, does what it does how ever it does it.