Global Variables

I was wondering whether or not there is a way for a script to use variables defined within another, without defining it itself. This is like Global Variables in other scripting languages.

If so : tell me how and where to put it in both scripts please.

If not : please reccomend an alternative and keep in mind that I want multiple variables to be defined so llSay() and llListen() get pretty complicated.

Thanks alot.

There is no "extern" equivalent in LSL, so you cannot reference a global that is defined in one script from a different script.

Furtheremore, if both scripts are in the same object, then your llSay/listen approach won't work for communicating global values between scripts because a listen event doesn't get triggered by an llSay from the same object.

You'll have to use llMessageLinked to communicate global variable changes between the scripts.

- Ace

Okay, that's a bummer that there are no Global Variables. Maybe version 1.6

But the problem that I'm having with listen events is how to define multiple variables. Like I can say listen for (string) message, and set the first value. But then when it listens for the second value and sets it, won't it also set the first again? Or does the order of the listening matter? Would different states with listening events work? I'm just looking for an easy and understandable way to do this.

Thanks again for the help.

1. Don't use Listen if the two scripts are in the same object. Not only is it uneccesary lag on the server, the object won't be able to hear itself. Use llMessageLinked.

2. Unless you're -absolutely- certain certain values in an llListen() will ALWAYS be true, don't use them to filter listen() messages. My typical llListens are llListen(0,"",NULL_KEY,"";, the channel changingto fit my needs, the rest staying exactly the same. I use if() statements inside the listen() event to filter out messages that aren't the right ones, usually by using llParseString2List() on the message and testing each part of the list generated, usually the first element, for a recognized command.

Think key-value pairs. Your listener would be listening for anything and checking against a list of keys and getting, or setting, the associated value. Could even be done generically with a strided list, but be careful, as lists in LSL are immutable, so can cost you big time to modify.

Btw, be careful passing strings if you don't have to - it's rather easy to run into a performance surprise. Let's just say my Commadore 64 is laughing hysterically at LSL.

Careful with link messages if performance is an issue, they are MAD slow, just putting a listener on the object is way (way) faster. I have never encountered issues regarding this unless they were bugs in the game itself.

I have moved from a centralized model (where one object is an "engine" and feeds all the rest data) to a distributed component model (where perf-critical objects receive the data directly as opposed to via a link message from the central source) and the performance is WAY faster, which has finally enabled my FPS hit point meters to work in the appropriate real time in some of my game code. This is a pretty typical code model evolution for anything perf intensive, and it's panned out in LSL.

Minimize your link messages is the lesson I learned.

I toyed with a structure to enable global variables in a way...create a script that does nothing but track variables, and create a few facade methods to enable automated calls for name value pairs, which can work through link messages or llSays. I laid out a structure like this at length some time ago in the forums to be able to access a scripts members as a collection, and implemented it in some of my game mechanisms, but it seems the old posts have been lost .

Link messages are extremely fast (20 milliseconds or so), what are you doing that appears slow with them?