Not quite, Jaxith. Your card design is certainly one way of doing it, though there are problems with the code, but it wouldn't work with the way I've designed the system.
My idea, remember, is that the door uses a temporary channel based on the uuid of whoever has just touched it. That means, in practical terms, that its messages will only over be heard by an object belonging to the av who has touched it -- the card.
So if we are doing it my way, the card always listens on a channel based on its owner's uuid. It will calculate this in a slightly different way from how the door does it, using llGetOwner(). So to set the channel the card listens on, you need something like
integer mychannel; // global variable so we can use it anywhere in the script
default {
state_entry() {
mychannnel = = ( -1 * (integer)("0x"+llGetSubString((string)llGetOwner(),-5,-1)) );// I'm using llGetOwner() to get the owner's key here
llListen(mychannel, "", NULL_KEY, ""); //listen to messages from anyone using that channel
}
}
Then, in the listen event, after checking it really is for me (probably unlikely it's going to be for anyone else, since the odds against another object in earshot using the same channel are pretty steep, but why not make really sure?) by checking
if (message == (string)llGetOwner()) //I can never remember if you actually need to typecast a key as a string when you are comparing it with another string, since it's a sort of string anyway, but it's certainly never going to be wrong to do this
you reply on mychannel
llSay(mychannel, "something or other");
If your reply is the owner's key, then I think you will have to say (string)llGetOwner() to get it to compile.
What you include in the reply is up to you. My door, remember, checks that the message is from an object belonging to whoover has just touched it by using
if (llGetOwnerKey(id)== av)
Listen events automatically grab the uuid of whatever they've heard -- that's what "key id" in "integer channel, string name, key id, string message" is all about -- and llGetOwnerKey(id) gives you the key of whoever id belongs to. Which should be the as av, which is whoever just touched us.
So all I've done in my code is satisfy myself that whoever has just touched me is wearing (or has rezzed in earshot) something that knows to listen on a channel calculated from its owner's uuid and to reply on the same channel. It's up to you if you want to include futher checks like if the message received by the door also contains the uuid or infomation about access levels or a password or whatever.
In your script, llListen(-214748, "", llGetOwner(), "" ); means always listen on channel -214748 -- which is almost certainly not going to be the channel the door's using if we are doing it my way and also means "only listen to messages from my owner". So, even if the door does happen to be speaking on the right channel, we ignore it. In fact, we will never hear anything, since avatars can't speak on negative channels -- only objects can do that.
If you are designing the system differently, and want to have the door and cards always communicate on -214748, then you need to declare mychannel = -214748; before default (so you can then refer to mychannel anywhere in the script -- less chance of typos this way and it makes life a lot easier if you want to change the channel for any reason, since you just have to alter it there). Then in the listen event, you have
llSay(mychannel, (string)llGetOwner()); // or whatever you want to card to say
)