Jump to content

Global variables across multiple scripts


Ronie5ive
 Share

You are about to reply to a thread that has been inactive for 3778 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

No.  "Global" means "accessible anywhere in this script", not "accessible anywhere".  Fortunately, you rarely need to have multiple scripts in the same object any more, and many scripts that have to communicate between objects don't need to send more than a few pieces of information at a time. 

You have a few handy ways to initialize variables in newly-rezzed objects. 

1. You can send integer values in the parameter that is read in the new object's on_rez event.  That is, if you want to send the current value of a variable named "Horse" to your newly-rezzed saddle, you can write

integer Horse = 2;llRezAtRoot("Saddle",llGetPos() + <0.0,0.0,1.5>*llGetRot(), ZERO_VECTOR,ZERO_ROTATION,Horse);

 With some cleverness, you can sometimes encode other variables (like vector variables) as integers to use this method.

2. You can use the object_rez event to send a targeted message to a newly-rezzed object, using llRegionSayTo.  This works because the object_rez event picks up the new object's UUID:

object_rez(key id){    llSleep(1.5);    //Sort delay in case of lag    llRegionSayTo(id,my_channel,(string)color); // Send color vector as a string}

3. You can send inventory items from one object to another, and the name of a sent item can itself be a message.  For example, you could send a notecard full of information to be decoded on receipt, and then put a script like this in the receiving object:

string gCard;integer gLine;key gQuery;default{    changed (integer change)    {        if (change & CHANGED_INVENTORY)        {            if (llGetInventoryNumber(INVENTORY_NOTECARD) == 1)            {                gQuery = llGetNotecardLine ((gCard = llGetInventoryName(INVENTORY_NOTECARD,0)), gLine = 0);            }        }    }   dataserver(key id, string data)   {       if (id == gQuery)       {           llSay(0,"The new card named " +gCard + " says, \"" + data + "\".");           llRemoveInventory(gCard);  //  Eat this note       }   }}

 

 You can make your dataserver event as complicated as you like, of course, and you can imagine writing your script to respond in different ways to different notecards.  The mind fairly boggles.

4. You can of course send values at any time later with any of the standard communication methods (llSay,llShout, llWhisper, llRegionSay, or e-mail or HTTP).

 

 

 

 

Link to comment
Share on other sites


Ronie5ive wrote:

Would there be a way to declare/initialize global variables across multiple scripts? It would make things so much easier for me!

Yes, it is possible.

But how it's done depends on a number of factors:

 

  1. Are the scripts all in the same prim? If not, are they all within the same object? If not, are they all within the same region? Each of these progressively requires more "reach" to access these GLOBAL variables with more coding complexity that culminates with requiring HTTP clients and servers. And the further the "reach" is, the more the second consideration comes into play.
  2. How sensitive is the information contained in these GLOBAL variables? Making GLOBAL variables available to other scripts exposes them as well to the outside world. Encryption, possibly even authentation, of critically sensitive information may be required (with its required overhead).
  3. However, overriding all of this is the consideration of how these GLOBAL variables are updated: If only one script can update these variables and all the rest can only read them, then you don't have to consider race conditions (see http://en.wikipedia.org/wiki/Race_condition#Example and think of each program as a thread, which (in fact) it actually would be) and a number of other "gotchas!". But really, even if just one script can update these GLOBAL variables, your programs will necessarily have to account for any number of considerations that arise in distributed computing (see http://en.wikipedia.org/wiki/Concurrent_Programming).

With all that said, if all your scripts are within one child prim and the information isn't sensitive, it's actually rather trivial. Just use llGetObjectName() and llSetObjectName() to hold your variables with a pipe (|) separator and ObjectDescription as a locking mechanism.

Link to comment
Share on other sites

One other handy trick, for scripts within one linkset. The description field of any prim in the linkset can be used as a place to store variable data. So each prim in the linkset could, in effect, be used to store a data value, accessible by all scripts in the linkset. I used that trick for a HUD once, storing an alphanumeric srting value in the description of one prim, and the scripts updated the description to indicate various states. For another project, I have a local teleport bracelet that stores one set of teleport coordibnates in each prim in the bracelet, allowing it to store ten teleport locations within a sim.

Link to comment
Share on other sites

Another consideration with GLOBAL variable(s) is whether there is a PUSH or PULL requirement.

 

If an individual program need only check the value at times, the variable would be PULL, you'd pull it's value from wherever it's centrally held; by reading a prim's description or such. However, if the programs must react whenever a GLOBAL variable's value changes, then it's a PUSH variable in that you'd have to have a mechanism implemented to push the update out to the other scripts and each program must need have an event handler, such as listen() or link_message(), that would trigger on the change.

 

Anyway, a beginning scripter might wish to learn all they can about inter-script communication before going this direction. Study https://wiki.secondlife.com/wiki/Category:LSL_Communications to gain an understanding of this and, while you master that (and, for that matter, even after you've mastered it!), try to keep with one script solutions.

 

Getting multiple scripts to work together isn't easy and requires a bit of thought ahead of time.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3778 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...