Global Variables

Is there a way to have 2 scripts within an object, and have one of the scripts set the global variables for the other? I want the people to whom I'm giving the object to be able to modify the global variables, but not be able to modify the script that contains the actual code. So they could, for example, set the channel the object listens on, but not modify what it does when it hears the commands.
llMessageLinked was a horrible disappointment. It did everything I wanted it to do *except* be able to modify global variables. I've searched but have been unable to find a solution.

Ah but it's what you need. Just set the global variable in the link message event on the main script. Since you can pass two strings (use the key field as an extra string), you can pass the variable name in one string and the contents in the other string. Just cast it to string and back.

Maybe I'm not sure what you mean, but I've been unable to get llMessageLinked to alter global variables. Here's an example of the code I've been using. The first (main) script looks like this:

key keyPerson = "00000000-0000-0000-0000-000000000000";
string strName = "";

default
{
    state_entry()
    {
        llRequestAgentData(keyPerson, DATA_NAME);
        llRequestAgentData(keyPerson, DATA_ONLINE);
        llSetTimerEvent(30);
    }

    
    dataserver(key queryid, string data)
    {
        //strName = data;
        if (data=="1" || data=="0")
        {
            if (data=="1")
            {
            	llSetText(strName + "\nOnline",
                    <0.0,1.0,0.0>, 1.0);
            }
            else
            {
                llSetText(strName + "\nNot Online",
                    <1.0,0.0,0.0>, 1.0);
            }
        }
        else
        {
            strName = data;
        }
    }
    
    timer()
    {
        llRequestAgentData(keyPerson, DATA_NAME);
        llRequestAgentData(keyPerson, DATA_ONLINE);
    }

    link_message(integer sender_num, integer num, string str, key id)
    {
	if (num==5)
	{
		keyPerson = (key)str;
	}
    }

}

and the other script is:

default
{
    state_entry()
    {
        llMessageLinked(LINK_THIS, 5, "00000000-0000-0000-0000-111111111111", NULL_KEY);
    }
}

Now it should switch who it is checking for online status from the all 0s to the 1s. But as soon as the timer is called, it switched back to the old variable.

Other than some inefficiencies, I don't see the problem offhand with the script.

Are you sure you aren't resetting the script together creating a sort of race condition?

Try adding something like:

link_message(integer sender_num, integer num, string str, key id)
    {
        llOwnerSay("Received link message: num = " + (string)num + ", str = " + str);
	if (num==5)
	{
		keyPerson = (key)str;
	}
    }

That will tell you if the message was received, and its contents. Like Gigs says, it's possible that the other script sent out the message before this script was ready to accept it (if you reset them both together), and so the message was lost.

You could also have global variables set in a notecard which is then read. The notecard could be very easily changed while the script is locked up tight.

Regarding what you have, the only time that the second script will send out the information is when it is FIRST rezzed or when it is reset. So, for this to work, the first script needs to be running when you start or reset the second script.

Baron

hmmm. I must be doing something wrong. The actual scripts are (naturally) much longer and more complicated.
I did originally have it say when it recieved a message in the link_message for testing, but took it out once I confirmed it was recieving the message. When the main script receives the message, it does switch the variable (keyPerson) to the new one, but as soon as the timer event fires, the variable switches back to the original value.
I remember reading somewhere that llMessageLinked couldn't change global variables (/54/ad/101992/1.html) but was hoping it would work anyway.
I'm at work right now, but when I get home I'll have to try the striped down script above to see if it works.

ooo. That sounds promising. What is the command(s) to have a script read a notecard?

llMessageLinked in and of itself cannot change the value of variables, unfortunately. It can, however, with some help.

For example:

// The open (modifyable) variable setting script.
vector color = <1,1,1>;

integer SET_VARIABLE = 5;
default {
    state_entry() {
        llMessageLinked(LINK_THIS, SET_VARIABLE, (string)color, "color");
    }
}

// The closed (unreadable) main script:

vector color;
integer SET_VARIABLE = 5;
default {
    // ...
    message_linked(integer sender, integer num, string str, key id) {
        if (num == SET_VARIABLE) {
            if (id == "color") {
                color = (vector)str;
            }
        }
    }
    // ...
}

Also, consider reading values from a notecard instead.
==Chris

Make sure you don't have a global variable called keyPerson, and a local variable that's also called keyPerson and is defined in the link message handler. The compiler won't warn you, but you'll end up updating the local variable (since that will 'shadow' the global definition with the same name), so when you exit the link message handler, it will look like nothing's happened, because the global did not get touched.

many scripts I have seen uses a locked script (no mod/copy/trans) and a config notecard. Then the scripts reads the lines of a notecard and translates it into variables.

http://secondlife.com/badgeo/wakka.php?wakka=llGetNotecardLine

For small amounts of data I use the object description as a quick place to put user inputted information.

Here is an example of using a settings notecard from the lsl wiki

http://secondlife.com/badgeo/wakka.php?wakka=LibrarySettingsNotecard

This makes it easier for a non-scripter to change values and feel like he/she understands what is going on!

Baron

Grimace,

Link messages most certainly can set global variables in the way you are trying to use them.

Your problem isn't link messages, there's a bug in your script.

That other post was referring to something like a global shared memory space, which LSL doesn't support.

If you want to send me all the scripts in world, I'll tell you what the problem is. I understand if you don't want to share your entire source, but I'm a trustworthy person.