Let's say I have a compiled module with a number of global variables and some functions that use them: - Script Start ---------------------------------- int g_points = 0; function void ResetPoints() { g_points = 0; } function void AddPoints(int points) { g_points += points; } - Script End ------------------------------------ My question is: Where is the value of g_points stored - is it within the context, the module, or the engine instance? Thanks,

The script global variables are stored in the modules.

I was asking as I was confused about the notion of contexts vs modules. So if I understand correctly, the logical notion of a module is bytecode and a data segment (persumably part of a stack for the module), while a context is mainly a means for constructing requests from the host applications to the script functions or variables.

Thanks!

Just a question an NOT a request about global vars.

Using global vars that are module dependent leads when, like me, your using different modules, to write "expoted" function to access to 'global' vars.

Example :

in module_A

int iGVarModuleA;

void SetVar(int iValue) {
iGVarModuleA = iValue;
}

in module_B

import void SetVar(int iValue) from module_B;

void someFunc() {
SetVar(8);
}

This works perfectly, but is a little bit heavy ...

Could there be a more simple solution ?

AbrKen.

Well, you could write the import statements in a header-type angel script and add it as a script section. For example:

Module_A (as is)

Module_A_Header (script)---------------------
import void SetVar(int iValue) from module_A;
// other import statements here
---------------------------------------------

Module_B script ----
void someFunc()
{
SetVar(8);
}
--------------------

Obviously you need to add both Module_A_Header and Module_B script as scipt sections module "Module_B" in order to build it, but at least you have a common reusable header for Module_A.

SharkBait:

Correct. You could think of a module as a DLL, that has it's own functions and global variables. The context is only holding the function stack, much like a thread in the application.

I've come to realize that this goes against normal use of the word context in scripting libraries, and I might change the name asIScriptContext to asIScriptThread in a future version. I've also been thinking about making it possible to create sort of a clone of the module, which will use the same code, but will make the global variables local to that clone. But all this is for the future, and will not be implemented any time soon.

abrken:

Currently there is not a better solution for sharing global variables between modules. I may implement support for importing global variables to another modules, but I haven't analysed the impact of that, yet.