Right now my ROM codebase uses hard-coded room/obj/mob/area/exit progs that are attached to their respective entities via lookup tables sort of like ROMs spec_funs are handled.
Although it's kind of old fashion and far from elegant, since the progs are compiled with the MUD it means I have access to all data and don't have to support code for every single check and function like ROMs default mobprog system does.
Does anyone have suggestions for a scripting replacement that would allow for a very high level of control? I don't want to have to add a few lines of code to my scripting engine every single time I add something to a struct I want to check for or every time I create a function (like damage or transfer or whatever) I want the script to be able to execute.
I'm not necessarily looking for something that can be edited online. Having to reboot the game and/or even recompile is fine.
Well, my suggestion would be to use Lua … however, nothing will automagically solve the problem of new struct members or functions being exposed to the scripting engine unless you use some kind of automatic binding tool (which are finnicky and will require a good chunk of work just to get them running).
It's probably not an option for you to just move everything to the scripting language, because that would complicate the C side of things, but it would mean that you wouldn't have to do anything to your scripting language engine when you add fields. Functions you would still need to expose.
I guess you need to decide how much of your cake you want to have and how much of it you want to eat. The more you want your scripting language to be completely dynamic, the more you're going to have to shuffle around in the C side of things to support that dynamism. The less you want to shuffle around the C side, the more you are going to have to do in terms of adding glue between the scripting engine and the C side.
That said, the kind of glue you need to add is a great deal simpler and more robust than the evilnastycrazy stuff that mudprogs typically do.
What it comes down to is what can LUA (or anything else) offer me that makes all the work of implementing it worthwhile, that my current system cant? I have progs and they can do pretty much everything I want them to. Is there a reason to switch to something else?
Lua (note: not LUA) – or any other scripting language – will not be able to solve all of your problems for you without you doing any extra work. That said, what a 3rd-party scripting language does provide is the following:
- code relatively guaranteed to be bug-free - the code is maintained by somebody else - lots of people have used the code, which is good for many reasons - the code is more likely to be a full-fledged scripting language as opposed to some half-complete home-brew maybe-kinda-sorta-probably-not works language like mudprog.
But as far as Lua is concerned specifically, embedding it is an extremely easy task. Nick Gammon has provided a version of FUSS 1.7 with Lua embedded to implement a questing system, and the changes to the C side are relatively small. Of course, you will have to go in and learn the basics of the C<->Lua API. But then again, no matter what you do you'll have to do learning and thinking.
Now to answer your question…
Clearly your system isn't doing something you want it to do because otherwise you wouldn't be asking the question. So maybe the first task is to very precisely identify what it is you want. From your first post it seems that you want the scripting language to automagically figure out when a field was added to a struct or a new function was added to the code. I briefly discussed the tradeoffs in my previous post; if that is indeed what you're trying to accomplish I can say more about it but first I'd like to make sure that is exactly what your goal is.
I don't have any problems with the system we currently use, but it doesn't seem to be a very popular method, at least not anymore. Hard coding all of our game progs within the C is very flexible and although it requires a fair bit of work to add new ones, it works very well.
Lately I've been looking over the codebase and thinking of ways of making it a little more modern. If an embedded scripting language can do something better than just hard coding it into the MUD, great, but that's what I'm trying to find out.
Oh… all of your "scripts" are in C, not even in mudprog?
Whether or not an embedded language will do it "better" depends on what definition of "better" you are using. In general, having a scripting language makes it easier to change stuff without having to go into the C code. But if you don't mind editing the code and recompiling, then it's unclear how much of a difference it makes. That said, it's typically easier to do rapid-prototyping-type stuff in scripting languages than in compiled languages, at least in my experience.