What you are asking for will be implemented in 1.8.0, the version I'm working on right now. With 1.8.0 you will be able to compile scripts into different modules, each with their own namespace.

For version 1.7.1, the two alternatives are to either prefix or suffix each function name to separate them into namespaces, or create multiple engines.

Most of the overhead with multiple engines comes from the engine configuration. If you have lots of system functions or objects registered the overhead will be larger. A rough guess is about 30-50 bytes per called registration function.

I'm hoping to be able to finish version 1.8.0 by mid July. Note: this is not a promise as I'm very short on time.

Regards,
Andreas

We are already using Multiple engines in our game to get around that problem, everything seems fine but one issue i have had with these is the inability to use 'extern' style of variables. i would love to have different scripts running in the same engine with some variables which i can share throught these scripts.

Can we make a small compiler like interface within VS for each script to make sure each script is precompiled(during app compilation) to know if the script is syntax error free before starting the host app?

EddHead:

Version 1.8.0 will also allow interaction with script declared global variables, which would allow you to connect them between engines. The script functions would be more difficult to export to another engine though. I will think about it, maybe it will be possible in a future version.

The way to make a test compilation of the scripts is to write a dummy application that registers all the functions and object types, and then compiles the scripts. An application like this could even be made completely generic if the function and object types were put in for example a xml file. It would be a completely separate project though.

lxnyce:

People are probably not pushing for AngelScript because it is relatively new. The first public version was made available just about 1 year ago. And people also tend to look at what other professional developers are using, which would be Lua or Python. But, I'm seeing more and more interest in AngelScript as time passes. Someday, perhaps some really famous game developer will pick it up and tell the world that he'll be using it for his next game ;)

I know the lack of examples and tutorials is a real blocker when it comes to newcomers, but I'm doing my best to improve that along with the new features. I think the new overview that I recently put up on the site will help alot to show what can be done.

I will welcome any tutorials or sample programs with source code written by others. I can even host them on AngelCode.com if the author wants.

i dont think there would be any need to extern script functions(just variables would do) from one engine to another as of now, we could just send variables across. we could think about using a single engine instead with all the possibilities of multiple engines(to reuse functions), one thing i noticed was putting everything in the same engine would give line number changes during errors which would be hard to track, if that is fixed we can stick to one engine. but about multiple processes, i guess the load on one engine would be too much. one more workaround now is declare the global variables globally in the host application (kinda cumbersome).

your thoughts?

Currently I highly recommend having separate engines for tasks of different types, ex. one engine for GUI rendering and another for AI managing. This is mostly for safety, and simplicity.

Having one engine that handles different tasks of the same type will be much easier with version 1.8.0, because of the modules.

I'll verify the problem with wrong line numbers.