Now instead of creating 5 scripting engines, the 'group module access' feature sounded like the right thing to do. But soon I found several "problems", the first one I solved easily with some kind of hack, but the second requires modifying the angelscript code.
Here is the thing:
I've created as many *modules* as security layers we have, so I have 5 modules. Also I created one access group for each security layer, so I have also 5 access groups.
Each script presented to the engine will be compiled into one of the 5 modules.
Each layer requires access to all upper levels, but never lower. For example, if I define a global function in group 2: group 0,1 and 2 will access it, but group 3 and 4 will not even see that function. This was simply resolved by doing this:
void Scripting::UpdateAccessLayers(){ // Configure group access for(int i=0;i<SCRIPT_LAYER_COUNT;i++) { m_engine->SetConfigGroupModuleAccess(c_strGroup,asALL_MODULES,false); } // Each module has access the the same group layer and above for(int i=0;i<SCRIPT_LAYER_COUNT;i++) { for(int g=i;g<SCRIPT_LAYER_COUNT;g++) m_engine->SetConfigGroupModuleAccess(c_strGroup[g],c_strModule,true); }}
Now the first problem was that, I cannot simply configure this at startup and forget about it because somehow, new scripts will not respect this arrangement (becoming a security issue), so I solved it by updating access layers each time I add a new script section. This sounds more like a hack, but solved the problem.
Now the next problem I faced was that, even I cannot call functions defined in lower levels, I *can* import functions from modules that define functions in lower levels. I think this is possible simply because, when I define a new function *inside scripting* I cannot specify a group access. Is there a way to pre-define that all declared functions inside a script will USE a group access ?
Thanks!