Sure. Wrap it up in a class, and never think about it again.

Can you show me with an example of how you want it to work? I think I don't quite understand what you're trying to tell me.

The import statement will only work with the complete function declaration, as the compiler needs this information to know how the function is called.

If you don't want to have to remember all the function declarations with their parameters and return types, how are you supposed to know how to call the functions?

You never have to remember the section names, they are only used for compiler messages. If you don't want to have to remember module names, then compile all script sections into one module with no name.

The error locations will be correct as long as you don't alter the script file before adding them to the module with AddScriptSection(). Each file should be added with a separate call to AddScriptSection() where the section name is the filename.

yep, i have been using it this way,

AddFSMState( fsm1, ANGRY, "angryfunc" );

what i do is use GetFunctionIDByName to get the context for the function angryfunc and call this function from the FSM handler code, very convinient(which was what made me so obsessed with this library). i normally dont send more than 1 parameter, maybe like a single integer paramater. this helps em alot in dynamic behavior changing. i could explain better i guess...but my english sucks.

Sounds like a good way of handling it.

If you wish to use modules, then you could either add the name of the module as a parameter to the AddFSMState() function. Or you could pass the function ID instead of the function name:

AddFSMState(fsm1, ANGRY, engine->GetFunctionIDByDecl("module", "void angryfunc()"));

Yes, but like i said the module names are cumbersome, i would like to add module names only if i am handling it internally, since scripts are mostly used by Modders, i would like to give as minimal control to them as possible.

i would like to bypass the usage of a Module name.

Who is doing the calls to AddFSMState? Isn't that the your application when it loads the scripts for the AI entities?

Why would the script writers need to know the module names? Why do you need to use the import statement?

True namespaces would perhaps have been easier to use, but I haven't implemented them yet.

Most of the Modders i am talking about will be more advanced than the usual modder, i require them to have some coding knowledge anyway, but AddFSMState is an example. these are called in the script defs for FSM creation. (yes i want to be able Mod to that level).

Most of the time you don't need to specify the module name, because the application can obtain the module name from the context when an application function is called:

void func(){  asIScriptContext *ctx = asGetActiveContext();  uint funcID = ctx->GetCurrentFunction();  string modulename = ctx->GetEngine()->GetModuleNameFromIndex(funcID >> 16);  ... Do something where the module name is needed}