I have really broken my head over this. The API module system I have implemented actually allows loading of APIs by name, so the "worker" stuff could be made dynamic with only trivial effort.
However, adding actual methods to the script base class is proving a challenge. Specifically, language extension modules need to supply a file that augments a partial class, therefore must be present at compile-time. Of course, an invocation method osCallModule() could get around that, but i's a horrible kludge, IMHO. I'd much rather add native support for adding real methods, if at all possible. Theoretically, I can easily let scripts use "using" and reference additional modules. However, the LSL2CS converter errors out at every Class.Member notation, exclept for a few permitted ones. Therefore, this would become usable for scripting in other languages only, but not for OSSL. As I'm writing this, I actually thought of a way to do this, but I have to investigate further. The idea would be to do a text replace after the LSL translation. This means that I would have each module provide it's method names and the module name, and then the naked method names would be used in the script. Then, after parsing, the script would be scanned for the naked method names, and they would be replaced by "Module.Method". So, this: state_entry() { MyModuleMethod(); } becomes: state_entry() { MyModule.MyModuleMethod(); } and is then passed to the compiler. It would still have to use some form of call gate to break out of the app domain, which may need more references magic,but it seems doable and not too ugly. Melanie Justin Clark-Casey wrote: > Mic Bowman wrote: >> opensim currently has the LSL and OSL APIs that implement functions >> for scripting. is there an good/easy/appropriate way to add a library >> of functions dynamically? can i register new script functions through >> a region module? > > Just fyi Mic, there was also some discussion about this on > > http://justincc.wordpress.com/2009/02/27/reflections-on-writing-an-opensim-region-module/ > > with a few possible avenues from lsba71 and Rob Smart by which it might be > possible to get this done. However, they > would all require some infrastructure work if they are viable. > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev