Jump to content
  • Advertisement
Sign in to follow this  
fuzinavl

sharing globals between modules.

This topic is 4848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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 group
engine->BeginConfigGroup("group 1");
engine->RegisterGlobalFunction("void myfunc()", asFUNCTION(myfunc), asCALL_CDECL);
engine->EndConfigGroup();

// Allow only one particular module access to the configuration group
engine->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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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 behaviour

void groupthink()
{
}

int groupValue;
int getGroupValue()
{
return groupValue;
}

void setGroupValue(int value)
{
groupValue = value;
}


The individual AI scripts import these functions like so:


// Individual AI behaviour

import 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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 module
int 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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!