WitchLord writes:

Quote: Version 2.4.0 will allow the application to make groups of configurations and define which script modules should have access to which groups.

Does this allow me to share global variables, arrays, and possibly other data structures among several modules? (each character has it's own AS AI module.) That would be just what I need to allow players to implement group-behavior in their AI scripts. If a character were to switch teams (switch configuration groups), will AS 2.4 support that somehow, or would I release that character's module and re-initialize it's AI to become part of the other team (seems safer)? will AS 2.4.0 natively support new data structures like trees or lists? Or would you rather let the programmer do function binding to interface with C++ data structures? What will the new AS features' code (group configurations) look like? [Edited by - fuzinavl on August 8, 2005 4:08:25 PM]

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

ok, I like everything you mentioned :) , configurations look like they set permissions nicely without complicating things.

Here's the orginization that I want in my game:

1. seperate configuration groups for maplevel scripts and AI scripts
2. every character has his own module with a think() method.
3. every team/group has their module with a groupthink() method.

How to facilitate group behavior programming...
Here's my proposal:

1. I load and compile a groupbehavior module for each team
2. as needed, I load individual AI modules
3. before? the individual modules are compiled, I can declare (if I choose to) one (??? or more ???)of the groupbehavior modules to be its "header".
4. this gives individual AI modules access to groupbehavior module(s), but not the other way around.
5. If there is a "foo" variable in "header", none of the users of "header" may also declare "foo".
6. there is only one instance of "int foo" per "header" module! So if one user module changes "foo", all user modules see the change.
7. Maybe a keyword could be used to declare certain variables and methods as private (or public?) in the "header". Should the default be public for simplicity?
8. A module may not try to declare a "header" which is part of a different configuration. Is this the right way to go about avoiding bugs and hackers? Does it even make sense to do this? Is there a better way? Maybe no restrictions, and let the "C" programmer be responsible for this?

I would like to be able to use the current AS system for everything, but I don't know what kind of structure and logic people want from Groupthink()methods. "Headers" would allow them to define waypoints, group formations, and almost anything else without touching the "C" code.

I would like to know what other people think of this "shared headers" proposal.

[Edited by - fuzinavl on August 8, 2005 2:54:02 PM]

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

awesome!

now the characters can share groupvalue globals and groupMethods.

I'll just put that bit into my AI script writer's guide.
This opens up so many possibilities.
I'll have to give each team their own AS engine, to avoid cheating in the game.

the whole headers thing would gum-up the API with bugs anyway.

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

DUH! *smacks forehead*
I could even use BindAllImportedFunctions() in "C" code in such a way that it
forces an entityModule to import from the appropriate team's groupModule; even if two teams are using the same script code in their seperate groupModules. (what a long sentence)

Good news: I can still use the current version of AS!