Quote:
|
Originally Posted by kathgar
if we had a fullfledged scripting language we would not need to make additions to our language whenever we needed something.)
|
That isn't actually 100% true. If I were to do this in a Windows-only way, I'd expose eqEmu's guts via COM, so that eqEmu objects could be easily accessed via languges operating under the scripting host. It is really sexy, and super easy. It all depends on COM, though, and as far as I know, Linux doesn't have anything even close to this kind of capability/effort ratio. I am _not_ interested in getting into cross-platform corba or anything. So, embedded Perl is the next best thing. Unfortunately, without exposing eqEmu's objects via COM, we are limited to writing call-back type subs in Perl, synchronously moving variables to or from Perl, or direct manipulation of the Perl stack. This isn't a big deal, since call-backs are well-suited for event driven setups, like the one already written into eqEmu. However, the callbacks only work one-way - it isn't easily possible to have Perl scripts call existing C(++) functions. This means that most of the scripting functions will need to be implemented by maintaining state and variable passing, rather than interactive invocation. This means that the c code will have to be modified to expose some types of new functionality (essentially like the existing code).
I haven't started writing code yet, but this is how I'm envisioning it at this point... If Perl is compiled in, users will be able to replace .qst files with files containing perl code. The code files will contain subs, one for each event that the coder wishes to have handled. Each file will be read into a seperate namespace or possibly be wrapped into a class... not sure about this, yet, but that would probably be nicer than requiring a prefix for each sub or some such thing... Each parser object (read: each instance of the parser class) will have an instance of a perl interpreter. The interpreter would, thusly, be loaded only once and would therefore have minimal overhead (assuming we don't get excessively complex scripts). The memory footprint would vary according to global variable usage. Instead of exposing callback hooks, like "say" or "dbspawn" or whatever, variables would be exposed to indicate to the main parser module what actions the script needs it to take on its behalf. Likewise, variables (like $name) would be exposed to the interpreter in the same way that they currently are. All of this should be possible to add in fewer words than have been used in this post so far :)
About global variables... this part is very cool, and is weighing in on my scope resolution decisions. Global variables would be avaliable to all scripts running under the same parser (i.e. to all npcs in a zone). This could make for some very interesting quest implementations... You could keep track of who's gone where or send messages between multiple npcs or cache global data (like database connections). All kinds of neat stuff.