Hello again,

So, I was again thinking about 'Advanced MUD Concepts' and remembered reading something a while ago about a coder who implemented SLang into his game.

I thought it might be worth it to start a thread about such things.  I've done some work with the Python API, but never in a MUD setting.  

Another question might have to do with licensing of these languages?

Anyway, at the risk of insulting the authors, MOBProgs, at least under MERC, are less than streamlined, and not as extensible as using a legitimate programming language.

The major issues I see with this have to do with attaching your language of choice to the MUDs datastructures, concurrently, no less. This, I suppose, could be accomplished with ah run-time library? or perhaps a control server, but that opens a Pandora's box of Security issues.

-Xanes Lone Coder -=- WinterMUTE

when it comes (well if at the rate i'm going) to the time when i have to implement mob scripting, i think i might try to embed python, as its already a predefined language..

My only issue would be to find out how easy it is for non coder oriented people to learn, as i'm not sure builders would want to try to figure out something confusing.

Its been a while since I last programmed in LPC, but while I liked it as one of my first languages I learned, eventually it came to feel limiting.

These days I program for a MMOG in Python and I like it a lot. My current iteration of my own personal project, more a simulation than a MUD, is in Python.

Actually, since my last comment, i've heard good things about ruby. thats another simple thing to look into... and i am pretty sure ruby has a configurable sandbox to prevent users from being able todo maliuous things

Well, I can only say that my exposure to scheme (which is embedded into our MUD as a scripting language), lead me to read SICP - which in turn lead me to a better understanding of programming. While functional programming might seem alien at first, it also offers very interesting insights. In addition, there are two packages available that directly integrate with java so you can manipulate all java objects from within scheme without much additional code.
Python certainly is a good option, too, because it might look more familiar to those whose only "programming" experience is in mobprogs. By providing your builders with an adequate set of pre-coded functions I am sure it is a nice solution - and easily embeddable into C if that is the language you use for your MUD.

I think I understand you correctly.

Two things: You'd have to make sure that they couldn't execute any commands you didn't want them to, and put in the commands you wanted them to use: by the time you're done, just write your own language.

The other problem would be the compiling problems. MProgs are interpreted , not compiled (like BASIC), and I'm not sure whether Python is interpreted or not, but any compiled language could give you problems.

Well, the security issue vanishes totally if you do not allow your builders to add scripting-code online but only after one of the implementors has checked the scripts (the approach we take), or have a separate building port as in many LPC-muds. The security issues are very much the same if you use MProgs, with MProgs having many drawbacks: Among a few are no "clean" syntax, no looping constructs, no variables. Add to this, that MProgs are difficult to maintain, because they offer no direct access to the data structures of the MUD, making it necessary to add new if-checks and mob-commands on a regular basis.
Basically, they're a nice little tool for very small tasks, but as soon as a mobile's gets more complex than just walking around a bit, handing out the one or other item and having it say a few lines, they quickly become bloated and difficult to read and debug - using a full-blown scripting language will make a lot of tasks a lot easier there.
As for the compilation-issue, maybe I did not really get your point, but I do not really see any difficulties there, as the difference between compilation and interpretation is blurring more and more in modern languages. Most scripting languages are what one would classically call interpreted, but of course internally compile into some kind of byte-code which is then executed at far higher speed. Python, eg., offers a wide variety of options to execute code, ranging from instantiating a code-object over interpreting a string to executing a pre-compiled bytecode file. In addition, most of these languages offer very extensive bindings for at least C and Java, so there is comparatively little code that needs to be written to incorporate them.

Late last year I announced my decision to create a new MUD scripting language here. At that time I asked for suggestions (short of object oriented). Since then I have completed (some sugary items are still missing) the new language which I call BlobbieScript. At any rate the thought of embedding a language like PHP crossed my mind before I set out on that endeavour. At the time I had a couple of major problems top consider: security due to the wide array of functions, and backward compatibility. To switch languages would mean losing all of the pre-existing scripts on my MUD. Another thought presented itself too, PHP is a real programming language and to that end not very intuitive to the untrained builder. At WoC we used easyacts, I believe these are the predecessor of MobProgs, and as anyone might tell you, MobProgs are interpretted and (if anything similar to easyacts) macro based. Thus there was no support for real time variable access since variables were calculated then expanded through the script. This was unacceptable. Also there was no support for looping contructs, which brings me back to PHP, controlling infinite loops in PHP would require a thread so as to not affect the MUD itself. This opens up a whole jar of worms since the structure of DIKU was not designed for such things. At any rate my final decision was to make a 100% backward compatible scripting language, BlobbieScript. Having created the engine myself I was able to easily control the execution contexts (for looping) and able to retain 100% backward compatibility with easyacts. Now having had it active on our MUD for 3 months, I don't look back. The engine is tight and builders can create simple scripts that are like issuing the commands at their client whilst advanced builders can create almost anything their imagination can dream up (special procedures are defunct). Incidentally I also add a protected block contruct for emulating mutex/semaphore locking. Really the block just guarantees the block of code runs to completion before returning control back to the MUD server (there are checks in place for scripts taking to long to return control). Another advantage of writing my own engine was how easy it was to add support for stopping the code, stepping through it, and viewing the running scripts variables. The next step on our MUD is to convert all the socials, dreams, spells, and skills to use the new scripting engine. Currently builders can create custom commands or override existing game commands via script. Also on the agenda is to create a new type of zone command script that will deprecate the current zone command system and use scripting instead. Anyways hope this gives you another perspective.

Cheers,
Blobbie.

even on a builders port you still have to worry about creating a good sandbox, ie securiing what builders are able todo...

without a proper sandbox, it would be quite easy to have a builder on a builders port to issue a command that executes "rm -rf ~/" and have major problems ensue.

i know both python and ruby are good at preventing that sorta thing, i never did get into looking how well they integtrated though.