Listen only to item of same owner?

Ok, so in the design of one of my products I've come upon a snag that could cause a potential problem for my customers.

My design uses a object as a remote which sends a RGB vector string via LlSay to a Listen script in the product that changes the color accordingly.

My problem is I need a way to secure the communications between the remote and the product so it will only listen to commands from a remote of the same owner.
Otherwise, anyones remote will change the color if in range.

Anyone know a simple way I can fix this issue? :/

You can use llGetOwner and compare against llGetOwnerKey in the listen event. You can choose to listen to your owner, your owner's objects, or both.

key myOwner;

default
{
    state_entry()
    {
        myOwner = llGetOwner();
        llListen(42, "", "", "");
    }

    listen(integer ch, string name, key id, string msg)
    {
        key yourOwner = llGetOwnerKey(id);
        if (yourOwner == myOwner) {
            llWhisper(0, "You are my owner, or another object owned by my owner.");

            if (id == myOwner) {
                llWhisper(0, "Actually, you are my owner, hi!");
            }
            else {
                llWhisper(0, "Actually, you are an object owned by my owner.");
            }
        }
        else {
            llWhisper(0, "Go away, you pesky stranger.");
        }
        
    }
}

Awesome, seems to work in my script. i'll test it and make sure it doesn't get interferance from other remotes.

i'm not in world to try this yet, but i see a potential problem. you need to add a reset or something to the script so it detects the new owner. if it doesn't detect the new owner, it won't work. but if you're just implementing this into another script you probably already have that covered i'm sure

edit: er.. Yeah. What Ordinal says below. Maybe one day I'll learn to read whole posts instead of just a few lines..

Or, just

if (llGetOwnerKey(id) != llGetOwner()) return;

Neither of these are exactly laggy functions.

What would compel someone to sell that script, let alone give it away? It doesn't do anything.

I'd hate to break it to you all who didn't look at the date of the topic...

this has long since been solved and implimented into my products for a while now and I haven't had a problem with it yet.

FYI, I didn't need whole a script so of course it isn't gonna work by itself... I just needed to fix the listener function on my current scripts.

obviously in the current state, but tweak it a bit and implement stuff into it or vice vera, and why not?after all, i'm sure most scripts are created by chopping and adding pieces of others. just sayin. lol, i've seen the changed owner mistake many times, easy fix, but also easy mistake to make, which can make an object not work for the next person and also:

Do you guys read?

Look at the date of the posts.

Its been finished. YES it was added to another script. YES it works fine. NO it doesn't break on onwership change, at least in mine.

This was a request for a FIX to my previous listener code, not a request for a whole script. :/

Hmm, this script looks very unfinished to me, and will probably not work if it is not part of another script - for a start I suspect that, if the owner changes, it will break.

Perhaps I should just rewrite the whole thing and post a replacement, that might be quicker.

lol, i don't think it's necessary, this is the scripting tips part of the forums, not the scripting library, i was simply adding an additional tip to anyone who may be looking for this type of help in the future........rena, obviously you're not the only one that reads or looks for tips in the forums, or they probably wouldn't be here, just because it's fixed for you, doesn't mean other people won't benefit from the continuation of the discussion