CMUD, one more time

I keep going back and forth about whether to give CMUD a try as the place for my "good enough for now" curing system for Lusternia, which is intended to keep me going at least until either MUSHclient or Mudlet get a mapper I can live with (or someone else beats them both to the punch). Keep in mind that the choice here is between zMUD and CMUD; no one else has a mapper that'll do right now, so those are the options.

I keep dismissing CMUD because of instability problems, and each time I try to do some testing, I get the same reaction. The very latest version seems prone to locking up when I do nothing more than importing a set of super-simple triggers from zMUD. If I import an entire zMUD profile, it locks up in the Compatability Report, and when I go back in, they're imported, but munged up. If I paste a long string of #TRIGGER commands in (a tip recommended on the CMUD forum), it freezes up. Strangely, if I manually convert the zMUD .txt export of a folder into XML using some simple search-and-replace techniques, then import that, this seems to work just fine. Which means I can work around the inability to import, but that's beside the point. The point is, how promising can CMUD be at handling the complexities of a combat system when it locks up doing something as simple as processing 20 #TRIGGER commands in a row when it's not even connected to the MUD? How much progress can Zugg really have made in "we've worked really hard on stability" in v3 when I get code-blocked on the second step?

On the other hand, I wonder if I'm overreacting to doing the wrong tests. Instead of worrying about importing old zMUD code into CMUD without even learning how it handles packages and scoping first, maybe I should be just trying to code something in CMUD from scratch. Will it be as stable as MUSHclient? No. But is that what I need? No, I just need it to be no more unstable than zMUD.

If it were precisely as stable as zMUD, and precisely as scaleable and had precisely as good performance, I think it'd be worth the $20 to buy it just for other features: support for Windows later than XP, the chance to use GMCP, and the hope of future improvements in ATCP, the mapper, and other areas, as well as improvements in the scripting system. If it were just a little better, that'd clinch it. But if it's just a little less stable than zMUD, that kills it. I am figuring I can make a "good enough" system in zMUD despite its bugs and instability simply because I am limiting the scope of what it intends to achieve, and I intend to prevent many of the problems from getting me by building the system from the ground up with zMUD's limitations firmly in mind. But it'll be a near thing; even a bit too much zMUD problems will kill it, or leave it little better than the hodgepodge of stuff I have on my Lendren account already. So if CMUD's a little less stable, I can't afford the loss.

Thus, despite putting the CMUD possibility to bed twice already, I think I'm going to make one last try to take a useful-but-limited subset of what I've done so far for Rainbow -- probably the Queue subsystem -- and recode it into a fresh Lusternia profile in CMUD. Not import, but recode it from scratch, taking the time to learn how CMUD suggests such things can best be done, using its new scoping and script packaging, temporary variables, etc. Trying to avoid being limited by a zMUD-like approach.

If I can make that work robustly, quickly, and well, I can certainly expand the test from there to start replicating other bits of Rainbow, probably the Skills system next, then the Defenses system that's almost done in my zMUD version. If I can get through all that, and get the mapper working, I might go with CMUD after all. On the other hand, if I can't get through a CMUD-native implementation of Queue without hitting more problems that aren't explicable as just me not being familiar with CMUD, but are actually problems in CMUD, then I will bury CMUD again -- only for real, for good, this time.

A year from now I will probably think back on all the time I've put into this as being a silly waste of time. All this work put into something that's built on an unstable foundation? But I've been waiting for MUSHclient or Mudlet to become usable to me for more than a year now, and it feels like my characters in Lusternia are partially stalled while I wait, and there's no sign of anything happening. Maybe wasting all this time will invoke Murphy's Law and force someone to take more seriously those things I say about why the mapper needs a few improvements and render all of that effort wasted sooner. Which would be just peachy.

If not... who knows, maybe building something for CMUD or zMUD from the ground up with the limitations built into the design will achieve the stability that people think is impossible. Certainly the CMUD forum is full of people who think it's possible, and while few if any of them are Lusternia players, and Lusternia's complexity far exceeds any other MUD, nevertheless every problem Lusternia coders need to solve is a problem someone else also deals with -- they just don't have to do them all at once. So maybe it's possible. Maybe one day I'll be sharing copies of Rainbow (with selected people -- I'll take the advice of Treant's author and not throw it out to the general public, much as I'd like to be able to, for the good of Lusternia).