Send Message When Clicked

Anybody know of a script that sends an IM message to owner of prim when clicked? Showing name of avatar that clicked it?

Send me a pretty bolo tie and I'll send you the script

Oh all right! This should work -- you may miss a msg if a bunch of avatars touch the object exactly simultaneously .... but that's unlikely.


key owner_key;


// **************************** States

default
{
state_entry()
{
owner_key = llGetOwner();
}

on_rez(integer start_param)
{
llResetScript();
owner_key = llGetOwner();
}

touch_start(integer num)
{

llInstantMessage(owner_key, llDetectedName(0) + " touched.";

} //end touchstart


} //enddefault

At last, a question I can answer

default
{
	touch_start(integer total_number)
	{
		llInstantMessage(llGetOwner(),llDetectedName(0));
	}
}

Damn, I need to type faster
But good points on the change of owner, I always forget that

default
{
    touch_start(integer total_number)
    {
        integer x;
        for (x=0;x<total_num;x++)
        {
            llInstantMessage(llGetOwner(),llDetectedName(x));
        }
    }
}

This will make sure all names are sent to you, in case 2 touch it within the same cycle.

Oh, *giggle*, i was kidding. We give scripts away all the time here.

besides, now you have three answers, we'd have to fight over it ... and that just wouldn't be pretty!!
.

Or, for slightly faster results:

default
{
    touch_start(integer nDetected)
    {
        string message = "Touched by:";

        integer i;
        for (i = 0; i < nDetected; ++i)
        {
           message += "\n   "+llDetectedName(i);
        }

        llInstantMessage(llGetOwner(), message);
    }
}

You could even queue up touch data for periods equal to the script delay of llInstantMessage() and have a helper script do the communicating, but I'll leave that as an exercise for the reader.

actually it'll auto-queue up to the delay of any code being executed, since the touches will accrue will it's proccesing other code (and as a bonus when they stack this way they'll only stack one av of each name while the event is queued

and the fastest (but perhaps not most memory effecient) way I know of... for fun

//-- name the object to reflect what the request is for, like 'Bolo Tie Requester' =)
string gStrNotice;  //-- pre create variable for faster usage
key    gKeyOwner;

default{
  state_entry(){
    gKeyOwner = llGetOwner(); //-- pre store owners key for faster retrieval
  }

  touch_start( integer vIntTouched ){
    @Loop;
      gStrNotice += llDetectedName( --vIntTouched ) + ", "; //-- (--)faster than other decrement methods
    if (vIntTouched) { jump Loop }; //-- jump loop is faster than other loops
    llInstantMessage( gKeyOwner, gStrNotice );
    gStrNotice = ""; //-- clear variable for reuse later
  }

  changed( integer vBitChanged){
    if (CHANGED_OWNER & vBitChanged){
      gKeyOwner = llGetOwner(); //-- reinitializing a single variable is faster than a reset
    }
  }
}

general principals
_jump loops are faster than other loops
_--decrements are faster than other types of decrement
_testing true/false on a counter is faster than comparison (and we can get away with this because the counter by design will ALWAYS start at greater than 0)
_reusing the built in touch integer for the loop saves creating a new variable, so is faster
storing frequently called function returns is faster than repeatedly calling them (assuming they're the same
_global variables are faster to use in most cases because the don't need to be recreated (this may be counteracted by the need to clear them)
_updating a single variable is faster than reseting a script, and won't dump the touch queue if present

Quite true, but if you WANT to capture all those individual touches by the same avatar, especially if you were also capturing timing information.... Either way.


Ack! I'm much fonder of readable and maintainable code. And now that Mono is very close, I feel absolutely NO guilt about encouraging those principles. They'd better enable some kind of optimization. Not doing so would be a crime! Either way, we should have to worry a great deal less about processor cycles.

I did expect the llInstantMessage to send an IM, but really it is an inter-sim chat.
a) It appears in the chat window, not in an IM tab.
b) It seems that they are not logged if you log your IM's

So, depending of your application, it might not be what you are really after in the end. I have had to send emails instead in some situations where I could not afford to risk loosing the message.

IMs from objects show up in the chat history window, and are logged along with normal chat, not as an IM log file. They DO get delivered once you login if sent while you are offline (subject to the usual limit of offline IM messages), and they DO get sent via e-mail under the same circumstances if you have the option set to receive offline IMs that way.

What Hewee says is very correct. I just wanted to state that it is not completely an IM.