Hello. I come here with something i think it's an interesting question (hope it actually is ^_^) I was trying to make some script which are actually "entities" or "processes"; i like to call them Objects. Whatever the name, those scripts are intended to control one particular Sprite in the screen. For example a "projectile" Object would contain all the code to move a shot across the screen, a "character" Object would control a the player's character in the screen, a "monster" object would do the same for enemies... and so on... I've already created some C++ clases and functions which take care of animations, sprite loading, sounds, input handling, etc. and they are passed to the AngelScript Engine. There is a sort of "Yield" function, based on the examples of AngelScript's SDK, so that every Object can tell the main .exe when it has finished doing it's job for this frame. Now, the main intention of all this, is that scripts can create other Objects. For example, a Character Object would create a Projectile Object every time the player shoots. There could also be a Monster Spawner Object which takes care of creating some random enemies. Hope you are getting the idea. I was hoping that users of all this messy program could make their own Object, which means, they could declare some global variables to hold Sprite, Sound, Animation and other data, hoping that every Object that is created will have it's own copy of those variables, functions and, in general, it's own independent code. With this, we can create one type of Object and make it appaer tons of times on screen. The best example is the Enemy Object: We can place tons of enemies around the stage, by just changing their position and current animation; those could be recieved as parameters in the main function; those parameters change the global variables; later, every single enemy could have it's own current state, position, animation, etc. by just changing the Global Variables declared in the script for that Object, something the script itself can do. Now, my problem is the following: This cannot be achieved with contexts, since they share variables for the current module (Suposing every module contains the code for one Object). It can be done by using one module for every Object create, but this would mean that i'd have to recompile the code for that module every time a new object is created, which I suppose is not fast enought to do it on real time. I propose a "ClonModule" method for the Script Engine class, which creates a copy of one module, to a new module with just a different name; hoping, of course, that it would be fast enought to do it real time. Hope i was clear enought.

I'm recompiling the scripts for every new object 'in real time'. :/ (You can 'cheat' by using save/load byte code.)

mmm...
true... true...

Maybe cheat a little more by keeping the byte code in RAM :O

Yes, of course. Incidentally, it is on Witchlord's todo list.

Cloning of modules is indeed on my to-do list, and is something that I hope to be able to implement soon (in a couple of more releases). Though if you want speed while creating objects, then I really suggest you use script classes instead of cloning modules.

I prefer the syntax of the the-script-is-an-object style myself. I use global variables for all the object's data. What would I have to do differently to use a script class instead?

Quote: Original post by WitchLord
Cloning of modules is indeed on my to-do list, and is something that I hope to be able to implement soon (in a couple of more releases). Though if you want speed while creating objects, then I really suggest you use script classes instead of cloning modules.

Mmmmmm...
That could work too...

though... it wouldn't be as user-friendly :)

Sounds interesting enought to think about it

Actually, you can encase your script in a class declaration at load time, and, perhaps, use it unchanged.

It's actually a pretty good idea. You can quite easily wrap the common script in a class declaration like this:

class ScriptClassName{... user created script here}

The only difference is that the compiler won't accept initial values for the class members like it do for global variables. Instead the user can implement constructors for default initializations.

You can even force the user to implement certain class methods by having the class implement registered interfaces.

Once you have built the script you can create the script class objects with the engine's CreateScriptObject, and call the class' methods normally with the contexts.