We can probably assume that the module ID will be consistent. You simply define the order in the "header" file. The script compiles should probably also generate some .h/.cpp files that you can include in your project.

I already took a quick look at ASB, but I'm not really sure how it works yet.

The problem with the module ID will only arise if you load the modules dynamically. Example in one level you load modules a, b, and c. In another level you load only modules b, c, and so on.

I might be able to solve this by making the function IDs used in the byte code local to each module. When getting a function ID from the engine's GetFunctionID() you will still get the complete function ID with the module index. But when a context encounters a BC_CALL code it doesn't care about the module index (should be set to 0) and get the function from current module. In the future when AngelScript allow calls between modules, the module index will refer to a local table of module references. This should make the byte code indifferent to order of loading.

I will make these changes already for 1.8.1 so that it will be easier for you to use Gyrbo's contribution. For 1.9.0 I will officially include the save/load feature.

I must admit that I don't know how AngelScriptBind works either. I just know that it takes a pseudo header file (looks almost like a C++ header file) and generates the binds from that.

Oops!....i really did mean a syntax checker, to warn the scripter that a code has to be correct before starting the Host App if necessary, since i am using scripts to initialize. i realised this would mainly be a tool to help the developer, and is no longer needed once the script functions are finalized.

WitchLord: I was thinking about how this could be solved, but I couldn't come up with anything. Using a local table would indeed work very nice. You would store the name of the module and resolve it to a module ID on load?

EddHead: A syntax checker would be pretty easy to make. If you disable the checks for the existance of a functionn, type and variable you have a pretty working syntax checker. This in itself isn't very useful though. You could make it more useful by defining the host functions, types and variables in a sort of header and using those for checks.

Yes, with the local function IDs it would be necessary to store the module name so that the global function IDs could be resolved at load time.

I haven't decided yet on how I want calls between modules to work. I would prefer some sort of late binding, so that scripts can optionally tell the host application to load a module and bind certain functions. Exactly how I implement this will be defined in a future version. I will probably also allow registration of application functions in modules, so that the application interface can be exchanged dynamically.

EddHead:

What Gyrbo's saying is true. You should register the host application interface (but without any function pointers) so that the compiler will be able to catch errors in function calls, and use of global variables.

The Syntax Checker would help script modules within the host just to make sure the modder is writing a proper script, we can use it to precompile the script and display syntax errors, or even IntelliSense like stuff, would help right?

No doubt a syntax checker would be a valuable resource for script writers. With the addition of asCRestore that Gyrbo wrote it could even be used to precompile the scripts.

Let's hope someone will write something like this. I'm willing to host it on the AngelScript site, just as I did with AngelScriptBind.

I'm planning on using compiled bytecode scripts in my next project. Writing a precompiler is pretty simple, you simply take the parts from your game sourcecode that set-up the scriptengine and use them to create a stand-alone program. You still need to hack the code a bit to make dynamic module order possible. This is still very simple because calls to other modules aren't possible, so you can simply set the module id in the function id to the current module.