I think I may have brought this up before. Lets imagine a simple script a single line long : "int foo;". Currently, the memory used to store foo is 'owned' by the module. Any function calls into that module will modify the same foo. The model I have implemented is slightly different. Different 'game entities' may use the exact same script file, but they should each have a unique copy of the global variables in that script. I worked around this problem by duplicating the module. This, unfortunately, wastes a lot of space, because each module has a unique copy of the exact same bytecode. So I am after some way to share this bytecode data, but not share the script's globals. So, the globals can't remain the property of the module. I could store them on the game entity, using some generic mechanism, but this needlessly complicates the scripts. The globals also cannot be stored on the context, because a context can only execute one function at a time, and I do have multiple contextes running code in the same module with the same globals at the same time. A third class is needed, some sort of 'script instance'. Someone is going to suggest that I declare a class in the script, simply instance it, and call functions on it, but my goal is to remove as much complexity from the script file as possible. Someone else is going to suggest that I preprocess the script file and wrap the entire thing in a class, but that proves somewhat complicated when you consider #including things.

Would you be willing to use a dictionary class? Something similar to the session object in ASP programming?

I'm implementing such a class as an add-on for version 2.9.0. It will work like this:

dictionary dict;dict.set("my attr", value);dict.set("another attr", value2);

It's not exactly what you're asking for, I know. But maybe it can be of use to you?

---

I also intend to experiment with allowing the application to duplicate or clone a module. By doing this, the script engine will know that the byte code is exactly the same for both modules, so it can be shared, only the global variables will be duplicated in memory.

This actually have a similar result to my previous plan of having three layers: 1. module, 2. context, 3. thread. Where the module hold the byte code, the context the global variables, and the thread the current execution.

Cloning the modules is easier to implement, and doesn't add much complexity to the interface.

Cloning the module's bytecode would do exactly what I need. It's exactly what I'm already doing (except I have re-build it each time) If they can share the bytecode, it's perfect.

I'm not sure what you're suggesting with the dictionary class. It's pretty trivial to tack a key/value set onto the game entity, and I could certainly do it, but it, unfortunately, complicates the script. The idea is for the scripts to be able to declare a global variable, then just use it. It's the difference between 'a = b + c;' and 'set_var("a",get_var_as_int("b")+get_var_as_int("c"))'.

I know, but since any other solution isn't available at the moment, that's what I have to offer. :)