Global script variables cannot be shared between modules. You can share functions though, which would be able to change the global variables in the other module.

Application registered global variables will also be shared with all modules that have access to the configuration group, in which the variable was registered.

If a script module is using functions, types, or global variables in a configuration group, then naturally that configuration group cannot be removed until the script module has been removed first. If you wish to change the configuration group that a module is using, then you'll have to recompile the module. It's possible to store the values of the global variables first, and then restore them once the module has been recompiled if you need that (it requires a bit of work, but it can be done.)

AS will never natively support specific data structures like trees or lists, unless there is something that cannot easily be registered from the application. The any type is one such exception that had to be implemented natively, though I'm thinking about ways that it can be broken out to allow the application to register it instead. New add-ons, similar to asCScriptString, may be added that shows how to register these structures though.

The configuration groups don't really change that much in the library interface. It just adds more flexibility to the way the application exposes its interface to the scripts. Example:

// Register a configuration groupengine->BeginConfigGroup("group 1");engine->RegisterGlobalFunction("void myfunc()", asFUNCTION(myfunc), asCALL_CDECL);engine->EndConfigGroup();// Allow only one particular module access to the configuration groupengine->GiveModuleAccessToGroup(ALL_MODULES, "group 1", ACCESS_DENIED);engine->GiveModuleAccessToGroup("module", "group 1", ACCESS_GRANTED);

All configuration groups still share the same namespace, so you cannot register the same function in two different groups.

----

I definitely want to make developing AI routines as easy as possible, including group behaviour. If you feel that there is something that can be changed in AngelScript to make things easier for you, then please tell me so. That way we can work together on improving the library for everybody.

Regards,
Andreas

You should be able to do this already without the need for headers. The group module cannot expose global variables, but it can expose functions for manipulating it's variables. Example:

// Group AI behaviourvoid groupthink(){}int groupValue;int getGroupValue(){  return groupValue;}void setGroupValue(int value){  groupValue = value;}

The individual AI scripts import these functions like so:

// Individual AI behaviourimport int getGroupValue() from "group";import void setGroupValue(int) from "group";int think(){  setGroupValue(getGroupValue()+1);}

If you do the function binding manually, instead of using the BindAllImportedFunctions() you can easily translate the "group" name into the corresponding module name for the group. Functions can even be rebound dynamically should the individual change group.

I don't think you need to use headers, though it can simplify things if the group behaviour exposes many functions. The 'header' could easily be included in the individual AI scripts by adding a second script section to the module.

Regards,
Andreas

You shouldn't have to use multiple engines for this.

The only thing you need to do is to translate the module name in the import statements to the real module name used for the group AI behaviour.

Ex:

// entityModule is the name of the individual AI behaviour module// groupModule is the name of the corresponding group behaviour moduleint BindImportedFunctions(asIScriptEngine *engine, const char *entityModule, const char *groupModule){  // Bind imported functions  int c = engine->GetImportedFunctionCount(entityModule);  for( int n = 0; n < c; ++n )  {    string srcModule = engine->GetImportedFunctionSourceModule(entityModule, n);    // Is the import permitted?    if( srcModule == "group" )    {      string funcDecl = engine->GetImportedFunctionDeclaration(entityModule, n);      int funcId = engine->GetFunctionIDByDecl(groupModule, funcDecl.c_str());      if( funcId >= 0 )        engine->BindImportedFunction(entityModule, n, funcId);      else      {        // Function doesn't exist.         // Report the error, or leave it unbound, which         // would cause a script exception when called.      }    }    else    {      // Trying to import from other module than the group behaviour.      // Report invalid import, or leave it unbound,       // which would cause a script exception when called    }  }}

In other words, by manually binding the imported functions, instead of using BindAllImportedFunctions(), you can easily control the access as needed.

Regards,
Andreas