Bringing MOO into the modern MUD world -- Help Wanted

I just thought I'd introduce myself a bit:

I've been MUDding since about 1991, but mostly switched to chatting and hacking on MOOs like LambdaMOO, RiverMOO, and E_MOO, and like most other MOOers sort of disdained "combat MUDs". Now I find myself gravitating toward RPG MUDs again (currently enjoying the depravity that is HellMOO), and am pleasantly surprised to see the small MUD community staying active and even attracting new people.

These days, I find myself a more-than-dabbling MOO server hacker, in that I'm laying groundwork for serious rewrites to much of the MOO server codebase in order to support a couple of MUD projects I signed onto. I might even arrogate myself the new de facto maintainer of MOO should I manage to create any actual demand for the new codebase, but for now I'm happy with my own private fork. What strikes me is that even after all these years, I'm still finding MOO useful what with its pervasive permission model and seamless persistence. Things that MOO maintainers wouldn't conceive of before I'll do without a thought, because my cell phone now has more resources than the puny SparcServer 1000 that ran LambdaMOO all those years. I'd say I've got room to grow.

I decided to start from MOO because my earlier projects of starting a codebase from scratch ran into "analysis paralysis", where I basically got writers block as far as getting the hard work done. MOO may be old and crusty, but hey, it works, and it's easier to add features to that than design new ones from scratch

What I'd really like to do is figure out how many other people would be interested in an updated MOO server; and on the other side, how many think MOO is just totally inadequate for whatever reason X. I've got an experimental MOO branch where anything goes, so when it comes to supporting modern MUD features, I'm all ears, and I'd love to hear suggestions on what to add in order to bring it in line with modern MUD codebases.

Some suggestions like unicode and ANSI colors are already in, but beyond that I'm more or less working with vanilla MOO.

Sounds interesting. It is vaguely related to a project of mine here:



Related in the sense that modern servers (and modern clients) have a lot more power than when MUDs (and MOOs etc.) were first invented, so maybe we should put that power to use.

I did read that thread and quite a few others, before registering and posting. I'm concerned about that protocol specifically, since it seems to require the ability to parse and execute arbitrary Lua code. I can take my concerns to that thread though.

Since this lua protocol, ZMP, and ATCP all seem to follow the same IAC SB protocol# arbitrary-data IAC SE pattern, maybe I should just route any data in such sequences to, say, #0:do_telnet_subnegotiation()?

You mean server to client? You could do that, although in my implentation I just did sprintf's where I wanted and put the IAC SB 102 and IAC SE in the printf myself.

Note the requirement for strings, where you need to add a backslash before quotes etc.

In my implementation I did *not* add Lua processing to the server end (the SmaugFuss), instead keeping the client to server protocol very simple (however, still valid Lua).

In particular, in the client to server end the messages looked like this:



Then I just parsed that with a simple sscanf in C. That kept the server end simple.

Sending to the client is pretty trivial -- I'm referring to what would get called when the client sends such a sequence to the server. Actually, I'm not entirely clear as to whether this Lua protocol (what's it called anyway?), or others like it are intended to be bi-directional, or are they strictly server->client?

Right now MOO's answer to side-channel chatter with the client is to use the "out of band" prefix it defines, and usually the MCP protocol on top of that. I noticed that every few years the question of MCP support in MUSHClient comes up, though it does look like if I want it, I'm going to have to write it myself. Now I think the power and flexibility of MCP is pretty much dandy, but I would like to make it more transport-independent. Using telnet subnegotiations to transport this side-channel might do the trick. Are servers usually set up to understand telnet sequences coming from the client?

I don't think it has a name yet. Perhaps I should have a competition?

My current implementation is in both directions, however for simplicity the client to server direction is simpler.

As for MCP, from what I read so far it is normal text that you could write a few triggers for (and omit from output) if you wanted.



From what I saw in SmaugFUSS, no they are not. I spent a morning rewriting the low-level interface to handle that. However that is now on public record, so there is no reason others can't incorporate it.

As for the rest, before we get too bogged down in what the protocol is, I think you need to work out: what is the problem you are trying to solve? In my case I wanted to send down mapping information (eg. a list of exits), and receive (from the client) what room number we wanted information about. The requirements of the problem dictated the design of the solution, somewhat.

The specific problem I'm trying to solve is getting MOO to optionally speak to existing clients that use telnet options without necessarily requiring the major gyrations it takes to switch an existing client to and from binary mode. Tunnelling MCP through it would just be a bonus.

As for doing MCP in MUSHClient, I'll be doing that too. I did have one question: is it possible to define new keybindings for just notepad windows? I'm used to having F7 be the "submit" key for local editing forms in vmoo and tkmoo, but it's a bit more involved in MCP than just sending the text verbatim to the MOO.

I don't think the keybindings work in notepad windows, so I think the answer is "no".

Hey Sproingie,

When I first started playing, I spent a bunch of time on Lambda and really, really liked developing on MOOs. I don't remember everything I liked about them, but I do know that tinkering and playing with a MOO on my own local machine was the start of my interest in programming period.

There came a point where there was 'x' feature I wanted that just wasn't in MOO, and I knew I wasn't the one who was going to put it in. I needed to learn a lot more about coding and so I started playing with newer, more modern MUD codebases.

I would absolutely LOVE to see a project geared towards overhauling a MOO, bringing it up to performance standard, and taking feature development in new directions. I would also love to get involved in such a project.

Do you have anything live? I'm definitely interested in more information on this project.

I'll look for your posts, though my e-mail address is public and I use lockewarrior for AIM, and lockewarrior@gmail.com for MSN.

See yah' around.

I've nothing live in the sense of a running server that corresponds to my project, no. Right now I'm merely doing a little "gardening" on the MOO codebase and have it up on github at http://github.com/sproingie/NuMOO

It's not really in any shape where I would want to claim credit, all I've done so far is take Codepoint (the most mature branch) and *remove* some features in order to make it easier to add new ones. I've held off on massive breaking changes until I get a coherent vision for what I want in a new server before I go breaking compatibility.

Some of the goals I want to address:

• Unicode. Codepoint thankfully does support unicode already, but I'm unsure how mature the support really is. It certainly doesn't expose much functionality to the user. GammaMOO does have more user-accessable unicode functionality, but I know its unicode support is extremely brittle and immature. One related issue is that MOO may have to become case-sensitive by default, which would be an incredibly incompatible change, but I think it's naive to do what it does now and only case-fold within the ASCII range (not even iso-latin!)
  
• Performance. MOO would benefit most from JIT, which unfortunately is an area I have absolutely no experience in. Barring that, more aggressive optimizations could be employed in the VM, which would involve storing a program that doesn't necessarily unparse back to the original source code. Making the stored program representation more flexible would of course make a later JIT much easier.
  
• Legacy removal. The built-in parser is antiquated and inadequate and can be emulated with softcode anyway. These removals would simplify a lot of things, though it would also render it incompatible with any existing core. Is a MOO that could never run LambdaMOO or Waterpoint still legitimately a MOO server?
  
• Language and builtin function changes. It's the lowest-hanging fruit, adding a ton of new builtins and cool language features. I prefer to take a conservative approach there, one that wouldn't alter MOO's fundamental character of pass-by-value/copy-on-write everywhere. Obviously some kind of mapping type is first on the agenda as language changes go. Getting more advanced, things like closures and first-class functions turn out to be really interesting problems in a multi-user environment (emphasis unfortunately on "problem", especially with respect to things like security)
  
• Fundamental model changes. The Waterpoint folks already started down a path of turning MOO's elegant prototype-based object model into something more hybridized with classic class/object with the introduction of waifs. Now waifs are certainly handy for what they do, but I really don't want to continue the duality if I don't have to. I've been looking at one of MOO's "spiritual ancestors", namely the Self language for inspiration, but I think unless I'm as ingenious as they were when it comes to JIT (the Self JIT was basically the prototype for Java's HotSpot JIT) I haven't a prayer of porting most of its ideas.

You're using kdevelop?? :(

I'm checking it out. Wow, it has been AGES since I've worked with Lambda, heh.

To comment quickly on your points:

-Unicode: Good freakin' idea, heh.

-Performance/JIT: I'm inclined to go the JIT route, but I'm totally unfamiliar with what has already been implemented. Lisp provided a 'compile' function, enabling the user to specifically declare items to be compiled. I -really- like that. I also really need to examine this branch a bit before I have anything relevant to add.

Legitimacy: Who cares? People argue all day and night about what is a MUD/is a MOO/is a MUSH/waste of time. I don't think making it incompatible with an existing core disqualifies it as a MOO. It makes older MOO cores outdated, that's all. :)

You would PREFER a classic class/object approach over MOO's already 'elegant' prototypes?

I tried kdevelop and committed the project files for it, but I haven't been particularly happy with it, so I'm just using emacs with flymake.

As for legitimacy, you make a good point, though I might just decide to name it something other than "MOO" if it gets that drastically incompatible. Anyway, it's hardly all that relevant to development -- I just happen to be making a MUD codebase that starts from MOO as a base.

And I certainly don't want to replace the prototype-based system with class/object, far from it. What I want to do is unify waifs into the prototype system and lose the distinction that is starting to emerge. I think a consequence of this is that objects would have to become reference counted, which would result in a performance hit. I don't think the performance hit would be that bad anyway: MOO already throws strings and lists all over the place and those are refcounted.

Now that I have more time to put a post together, here's some other wild ideas I've had, not all of which are necessarily *good* ideas I might add:

• Use berkeley db for the database format. Flush "idle" objects to the db to compact the heap. From a performance POV, it's probably a wash; while MOO's memory use is unlikely to strain any modern machine, some MOO workloads do fragment the hell out of the heap, so being able to move objects around on the heap as would be needed for such a system would be a bonus.
  
• Use something even more exotic for the db format, like Cassandra. I can't think of an immediate use for this, since MOO data tends to be much more intertangled and coupled than most MUDs with generic and limited area/mob formats.
  
• Verb calls on non-objects, ala ruby and to some lesser degree python. Could get rid of most $list_utils/$string_utils stuff. However, I don't want them hardwired and becoming a junk-drawer of one-off functions, so it would still dispatch to softcode. The question is, what do I assign as the handler? A server option comes to mind. It also really cuts into type-safety if everything can have verbs.
  
• Generators. Would probably not even be all that hard, since MOO already has coroutines. One problem though is that they would introduce implicit suspends, and most MOO code tends to rely on the need for explicit suspend to have proper concurrency behavior. I don't want to complicate the concurrency picture that much, but I am going to have to come up with something, like maybe critical sections where suspends are disallowed.
  
• Some kind of list comprehension syntax. Python's syntax is appealing because it wouldn't introduce any new keywords. I'm also considering something more like LINQ, which would allow people to expand it in softcode (just implement the "SelectMany" equivalent)
  
• A mapping type. This isn't even controversial, I want the damn things. If I can make objects lightweight enough, I could use them for mappings (given some kind of "expando" property allowing one to add properties on the fly). Main problem there is objects have pass-by-reference semantics, and I really prefer keeping the pass-by-value semantics of MOO's "primitive" types -- it's something that really sets it apart. Then again I could also consider copy-on-write objects!
  
• First-class verbs as a type. "foo:bar" would create a verbref type, that you could pass around and call with function syntax. Not actually too hard, since internally they're pretty well encapsulated already. It makes security somewhat trickier to reason about though, since neither the receiver nor the verb name are obvious anymore when your code gets handed an arbitrary verbref. It's not inherently dangerous, but it does limit their generality a little bit.

Hello.

Are you guys still interested in modernizing LambdaMOO?

I suggest adding support for a handful of TelOpts and protocols becoming very popular in the MUDing community and being adopted by the developers of many text gaming clients. These additions would allow folks to script graphical interfaces using Lua and other languages within the frameworks of clients like Mudlet, MUSHClient, etc.

KaVir, a veteran coder and developer of GodWars, has put together a code snippet that handles all the telnet negotiation. It is a generic solution written in pure C, intended to be hooked into any telnet-based server. It includes TTYPE, NAWS, MSDP, ATCP, MSSP, MSP and MXP, as well as UTF-8 (using CHARSET) and XTerm 256 colors.

Is anyone interested in folding KaVir's code into the LambdaMOO server? I think it would open whole new directions to MOO developers and attract an audience of developers who wouldn't otherwise give MOO a look.

Thanks.

-DM

PS: You can look at the code here: http://www.mudbytes.net/file-2811

Have you seen the LambdaMOO stunt patches? It's on github: https://github.com/toddsundsted/stunt

And has done a ton of modernizing. Would probably be a much better starting point than stock lambdamoo. It includes the primitive verb calls, maps, you mentioned.

There was a discussion about integrating KaVir's code into LambdaMOO on the Moo Talk Google Group:

http://groups.google.com/group/MOO-talk/browse_thread/thread/619f8928a8699dc8/ab1bbaeaf0225b4d

It's out of band for what I can work into Stunt personally, but I'd be willing to help ensure that correct internal APIs were developed/used if possible, and that those APIs were maintained (or at least not gratuitously broken at some point in the future).

Todd

---

http://stunt.io/