So I had the nostalgic urge the other day to start whipping up a MUD. I was looking around on MUDConnector, trying to see if it was still active in some shape, size or form. Much to my not-surprise, almost no one posts on the forums anymore, neither do they post on other would-be websites such as mudfiles.com.
I downloaded a few different sources (vampire wars, masters of hatred and socketmud) and played around a bit with them, and then remembered I had something on here.
After spending a few minutes trying to find the download link (wtb maintained package, please?? Its not as if there is a daily release...), and spending an hour trodding through my own code to figure out how to even log in properly, I finally got it working. I had two conclusions at the end of that session:
1) If you insist on implementing a module system that loads modules so you can segment code into just that, you may want to mention, in documentation, the 'bare minimum' modules. That way you won't spend 35 minutes trying to figure out why nothing comes up until you figure out the config file format and what modules to load; after which you spend 20 minutes more trying to figure out why nothing happens in-game, until you realize that the parser is a module too and should be loaded if you want things, well, parsed.
2) Some of the BYOND bugs related to telnet that originally left the project in the dark back then seem to be gone. (Hit enter to continue) seems to resolve itself for telnet clients, both standard linux telnet and two different MUD clients; ANSI escape-codes no longer seem to count towards the automatic word-wrap (Although it still pains me that one exists).
It still remains to be seen whether characters still idle out by themselves after a time period (Why would you assume someone would want this, with no way to control its behavior?), and whether input() can cause the VM to leak memory.
Fun fun.
| 
/*
escape codes preceeding whitespace (at the beginning of a string only? not verified) result in said whitespace going poof.
------------------------------------------------------------------------
example:
"[ANSI_YELLOW] blah blah blah"
when sent to a telnet client will draw:
"[ANSI_YELLOW]blah blah blah"
To combat this, I have set all outgoing messages to be colored via
HTML and HTML only. BYOND automatically converts some messages to
escape sequence, but I think it only functions like so:
"if there is red, send the default red. if there is blue, send the
default blue. if there is red and blue, send the default magenta. etc..."
that means we'll be suffering only dark colors in telnet for a little
while.
------------------------------------------------------------------------
*/
Funnily enough, the problem does not exist when you let BYOND filter out HTML color stuff. I never reported it, because I wanted to make sure it was an error on my part.