I have a usage scenario for AngelScript and would like to ask if that is possible at all and what the best way to do it is:
I believe I have the easy steps figured out (but am open to suggestions):
- I register a set of interfaces with the scripting engine so the scripts can interact with my systems
- The scripts are going to be script classes that implement a set of event methods set by a specific interface (like onUpdate or onSetup)
- Although many different instances of those script classes exist, only one of the event methods run at a time.
- The system loads presets that reference script code. I would ideally have this script code in binary form when I load it.
The hard part would be:
- During developement of the presets, I would ideally be able to unload the script class definition for one preset and reload it with the updated code.
The main problem is that there will most likely be 300-400 of those presets active at one time, and only a hand full share the same script class so only those would need reloading. I traced AddScriptSection for a bit and found that although it uses a string table and index for the naming, the index itself is not really used and sections with the same name would be added more than once. I also found no way to unload a section, either.
Thanks for helping!
Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.
A module can be built from multiple script sections, but once the module is built, the original script sections are discarded. If the module is to be re-built then all the needed script sections must be added again. That's why there is no way to remove a script section.
Do you really need to have all script sections in a single module? Each module is independent, and can be rebuilt individually, so you can probably accomplish what you want by compiling your script classes in separate modules. If the script classes need to be able to communicate with each other, then you can implement that communication channel in different ways, e.g. function binding, shared classes, or messaging.