string to same-sim object by key

It'd go a little something like this:

// script in object A
...
key target = "e4...";
string message = "here I am.";
llSend2Key(target, message);
...

// script in object B
...
default
{ entry_state() {}
key_message(key sender, string message)
{ llSay (0,
"I got the message ("+
message+
" from "+
llKey2Name(sender));}
}



This way, two objects could talk to one another directly within a sim without resorting to channels where there could be any number of scripted objects within earshot that would have to be checked. There's a huge range of stuff we could do with this! (imagine obj B sending obj A its own ID, or spoken text, for example.) Lindens - are there any factors that make this type of event problematic?

Seconded.

Thirded, definately would decrease possible security issues dramatically, also it would allow us to not rely on llListen, llSay, etc... so much for object to object communication. It would decrease lag then, so that objects wouldnt need to constantly listen for anything on any channel.

Revision to Kohne's Suggestion:
Two things should be implimented, an event, and a library function.

for example:
key_message(key sender, string message)
as the event, and

llKeyMessage(key ToWhom, string message)

This could be an interrim solution for object to object instant messaging or replace implementation of the obj to object IM altogether.

-Chris

EDIT: had little misunderstanting with this piece of text: "Thirded, definately would increase security issues dramatically, also it would allow us to not rely on llListen, llSay, etc... so much for object to object communication." I meant that it would decrease possible security issues... oopsie...

Basically this would be a form of link messaging between non-linked objects. And yes, it would be handy. However...



Objects don't need to listen for anything on any channel; you specify a particular channel, and you can specify a specific sender, when you set up an llListen filter.

As for reducing lag, how do you know how much lag is created by an llListen filter that has a sender specified? Is it more lag than this proposed key messaging would entail? We don't have enough information about the implementation to answer questions like these.

Well, none of us really know how much lag certain function calls and events cause, I was just assuming, actually...

I would imagine it would take less sim power since the sim won't have to check if every object in range is listening to a particular channel. Checking one object for a event hook is quicker than check countless.....

I always would love for this to be implemented.

This is a great idea and has been discussed before as Obj -> Obj IM (Object to Object Instant Message). With the exception that you limit it to a sim while I believe previous requests have wanted global.

I nth it, btw.

Yay for that, nay for the "same-sim" part. I can send an IM to anyone anywhere in the world, so why not any object? For that matter, objects can already send instant messages, so why not take advantage of a paradigm already in place?

By the way, if you send an instant message to an object, as of now, it doesn't give you an error... it just says that the user is offline and the message will be delivered when they log in. I hope old stuff gets flushed out of there from time to time, 'cause I've had something sitting in there since May, and that object isn't ever coming back.