Chime's MOO thread

Chime

Putting a new thread here to talk about this, as it's come up in various other scattered threads repeatedly...

For a multitude of reasons, a non-zero number of us like MOO and would like to use it or something like it for a non-zero number of things.

For those with no idea what MOO is but eager to add to the thread, please first see MOO on wikipedia.

So, the lambdamoo hardcode. Most linux distributions shipping a copy of it have taken what was on the sf.net project. I did a full clone of their CVS (yes, this shit is old) repo, but found that it was only a repo of work done by the sf people, and stretches back only to 1997, which is rather disappointing. Does anyone have a copy of the original RCS files from the lambdamoo project, as worked on by Pavel Curtis at Xerox PARC (going back to 1992)-- or even more interestingly, the code by Stephen White tracing the lineage from TinyMUD?

It isn't necessary, but the information-archaeologist in me would love to have proper and complete records. @Tyche? I know you've posted in the past about hardcode distribution archives for MOO/CoolMUD/ColdMUD in the past-- But that was long ago, on WORA. What do you have, exactly?

Things I'm working on:

Further review of Cool/Cold
Examination of modern python-based games
Basic packaging of a modern easy-to-build moo with a mush-like interface in supplied softcode core

ZekeTheG33k

Once upon a time there was a moo coder out there that iirc went on to run a Chicago based wod mush. He was pretty fancy with his moo code.

Chime

@Seamus said in Chime's MOO thread:

Once upon a time there was a moo coder out there that iirc went on to run a Chicago based wod mush. He was pretty fancy with his moo code.

That sounded like the start of a limerick for a bit there....

To be clear: I would love to see a renaissance of urban fantasy mu*s facilitated by a better server environment. I think the game I want to make is more sci-fi type stuff-- but I will be trying very hard to make a modern, mush-user-friendly moocore that will make sheets, chargen, etc. a snap to deploy for most would-be game owners.

But we aren't there yet. SOON.

ZekeTheG33k

He had most of that. He coded MUSH command syntax into the MOO to make the conversion easier. There were still some rough edges, but they were not mountainous.

Chime

@Seamus said in Chime's MOO thread:

He had most of that. He coded MUSH command syntax into the MOO to make the conversion easier. There were still some rough edges, but they were not mountainous.

That's an option, but frankly I don't see much mushcode worth porting over in that fashion.

Ide

There's a small but active MOO group on Google Groups. MOO-talk maybe? They've done some neat things lately.

Also that game Wayfar 1444. Based on a release of HellMOO's core I think.

somasatori

@Chime

I literally laughed out loud when that picture popped up.

Lithium

@Chime I wouldn't discount the option of coding mux like commands into moo, it'd make it a lot easier for people who are used to that code to jump into the game and get involved. If the commands aren't what people are used to they tend to simply walk away.

Or make a really solid tutorial so that people can get the information on how to use the code upfront

RnMissionRun

@Chime

I would suggest going with MOO because it's still somewhat popular and lots of people know how to code, build, etc for it. It's also the only one of Cold, Cool and MOO that is still fairly up to date. I would not use the stock server code but rather the HellMOO server, which adds some nice features as well as a dictionary datatype. Stunt might also be a valid choice but I have never been able to get it to work. GammaMOO might work, also. For my own projects I use the HellMOO fork of the server, along with stock LambdaCore. The only real drawback to using MOO is that large games can easily use hundreds of megabytes of RAM and a lot of CPU, making it a poor choice for use on shared servers.

Cool is nice but utterly obsolete (it lacks support for for floating point numbers, for example) and lacks a decent starter core. I would not consider it for serious use unless you really, really like the idea of being able to interconnect a bunch of CoolMUDs seamlessly together.

Cold is awesome but the server hasn't been updated in more than a decade and can have issues running on 64 bit hardware. Documentation is lacking, you're have to sift though the default core to figure out how everything works. I've used Cold as the basis for several games over the years (none of which ever really took off, sadly). I still have a test server running with a core I've been tinkering with for many years. I can supply you with the address if you're interested in checking it out. The downsides to using Cold include nonexistent documentation and zero support (meaning, you'd better be able to fix any bugs or other issues with the driver yourself).

Evennia is probably much too bare bones at the moment to consider using it for a game unless you're really keen to do a Python MUD and won't mind investing a lot of time building the tools and infrastructure that would eventually allow you to build a game. At least it's well documented and you can get support from the author/community if you need it.

GamerNGeek

@Lithium said in Chime's MOO thread:

@Chime I wouldn't discount the option of coding mux like commands into moo, it'd make it a lot easier for people who are used to that code to jump into the game and get involved. If the commands aren't what people are used to they tend to simply walk away.

Or make a really solid tutorial so that people can get the information on how to use the code upfront

THIS. I can't count how many times I've gone to a game, and run into this. Honestly, if I go to your game and type "+help", "news", "+where", or "+who" and I DON'T get usable input back, you've lost me.

We are, as a community, a bunch of dinosaurs. It doesn't matter if it's BETTER, but if it's DIFFERENT, you've lost us. You can put in new things, you can run on a different engine, but "backwards compatibility" must be 100% or you lose people. Sad, but true.

Lots of projects over the years have not thrived because of that simple truth. Hell, I once was on a Mush where I wanted to do something as simple as replace the "+" in +commands. Make it so "+finger" was just "finger" and "+where" was just "where". I got SO many complaints it was unbelievable. So the old + versions went in as aliases. I kept my new, but kept the old too, and people seemed okay with it.

Tyche

@Chime

I have a bunch of old MOO stuff here:
ftp://ftp.sourcery.dyndns.org/archive/servers/tiny/moo/
The oldest code I could ever find was the 1.6.1 version from August 1992.
It has the RCS comments in it going back to 1990, but there is very little if any Tiny code in there or evidence of Stephen White's hand in it.

This site has a lot more recent/semi-active links:
http://www.lisdude.com/moo/

Apos

@GamerNGeek said in Chime's MOO thread:

Lots of projects over the years have not thrived because of that simple truth. Hell, I once was on a Mush where I wanted to do something as simple as replace the "+" in +commands. Make it so "+finger" was just "finger" and "+where" was just "where". I got SO many complaints it was unbelievable. So the old + versions went in as aliases. I kept my new, but kept the old too, and people seemed okay with it.

Yeah, I've been aliasing basically everything to try to capture as many different MU syntaxes, though the truth is there's so many different conventions it's pretty hard to catch them all. Some commands have like five different aliases.

Arkandel

@Tyche It's not clear who helpfiles in most games are aimed for; the vast majority are stock ones and all over the place (referencing cash options or dates inapplicable for the MU* in question, for instance) so they're not there for newbies.

To top it sometimes you can get information with +help $command, other times you need to get the syntax from typing $command without any argument, and it gets worse when it comes to CGen-specific things (which, quite often, you'll find what you need on the wiki... if you're lucky).

Chime

@Tyche said in Chime's MOO thread:

I have a bunch of old MOO stuff here:
ftp://ftp.sourcery.dyndns.org/archive/servers/tiny/moo/
The oldest code I could ever find was the 1.6.1 version from August 1992.

You do not disappoint! Very nice.

All of the source releases have the RCS comments (from $Log$ entries), so that's not new, but having the 1.6 era tarballs is a nice feature.

It has the RCS comments in it going back to 1990, but there is very little if any Tiny code in there or evidence of Stephen White's hand in it.

He's still in the attribution list, though with the nebulous "portions copyright" bit. I'm not bored enough yet to go token by token looking for similarities with a MUD ancestor yet.

This site has a lot more recent/semi-active links:
http://www.lisdude.com/moo/

Also very helpful; has a good collection and explanation of a lot of the patches out there. The WAIF stuff in particular I'd already pulled out of the SF cvs archive, but having the additional context and link to the author's site is good. Not sure what I want to do with all of those cores, but they might be useful for reference.

Lisdude had a link to wrog's more recent github copy of lambdamoo-- didn't realize that was out there, but now I do. It seems to be a fork of some other random person's git based copy of lambdamoo that wasn't generated from the original cvs repo. Kids these days have no respect for the roots...

Anyway, going to gather up the trees coherently and make a more modern github release for reference. Thank you for archiving those source trees!

@Lithium said in Chime's MOO thread:

@Chime I wouldn't discount the option of coding mux like commands into moo, it'd make it a lot easier for people who are used to that code to jump into the game and get involved. If the commands aren't what people are used to they tend to simply walk away.

Planning to support most MUSH/MUX style commands where possible, yes. This is generally best done in softcode on a moo.

Or make a really solid tutorial so that people can get the information on how to use the code upfront

The goal of this project is that a typical MUSH player will be able to login to MOOs using this server version and core and not need to write any code; everything will mostly just work like they want it to.

Anyone wanting to add new commands will need to do it in the MOO fashion, which is already well documented.

But yes-- I expect documentation and tutorials are a huge part of the work.

@RnMissionRun said in Chime's MOO thread:

I would suggest going with MOO because it's still somewhat popular and lots of people know how to code, build, etc for it. It's also the only one of Cold, Cool and MOO that is still fairly up to date.

This is why we are here!

I would not use the stock server code but rather the HellMOO server, which adds some nice features as well as a dictionary datatype.

I'll have to take a look. I think the WAIF type is similar in utility, but if hellmoo's dictionaries are more robust then by all means.

Stunt might also be a valid choice but I have never been able to get it to work.
GammaMOO might work, also.

Both on the list to examine.

For my own projects I use the HellMOO fork of the server, along with stock LambdaCore. The only real drawback to using MOO is that large games can easily use hundreds of megabytes of RAM and a lot of CPU, making it a poor choice for use on shared servers.

So do MUSHes if you raise the LBUF limits to reasonable values. The Reach frequently hit 300-400MB RAM.

I think the real difference here is that MOO operates exclusively in what MUSH people call "in-memory" mode. MUSHes have been altered many years back to shove values to disk so they can run in very tiny amounts of ram.

While that is certainly an option, virtual memory handling, ram cost, and a variety of factors have changed over the past 25 years. I'll work on memory usage if it becomes a problem, but approaching that first seems like a premature optimization.

Cool is nice but utterly obsolete (it lacks support for for floating point numbers, for example) and lacks a decent starter core. I would not consider it for serious use unless you really, really like the idea of being able to interconnect a bunch of CoolMUDs seamlessly together.

Ew! We like floats. I'm going to need them for my KerbalMOO. (heh!)

The inter-mud connectivity that cool had is really interesting stuff but I'll have to think about how those concepts could be used in a more modern setting. I do see potential for distributed MOO data storage and processing being a useful feature for scale-able cloud-based hosting. And that has to win some horrid buzzword bingo, ew.

Cold is awesome but the server hasn't been updated in more than a decade and can have issues running on 64 bit hardware. Documentation is lacking, you're have to sift though the default core to figure out how everything works. I've used Cold as the basis for several games over the years (none of which ever really took off, sadly). I still have a test server running with a core I've been tinkering with for many years. I can supply you with the address if you're interested in checking it out. The downsides to using Cold include nonexistent documentation and zero support (meaning, you'd better be able to fix any bugs or other issues with the driver yourself).

I may need to do that, but I've got enough things to peek at for the moment. MOO has fantastic documentation, and that's one of its greatest strengths.

Evennia is probably much too bare bones at the moment to consider using it for a game unless you're really keen to do a Python MUD and won't mind investing a lot of time building the tools and infrastructure that would eventually allow you to build a game. At least it's well documented and you can get support from the author/community if you need it.

Again, on the to-do list to take a more detailed peek. I'm not a huge Python fan, but it's better than a lot of choices for that sort of thing.

Regrettably, I became a Perl expert back when that was popular. Python feels clunky, at least until I have to read someone else's Perl-- then Python seems quite nice.

Tat

@Lithium said in Chime's MOO thread:

@Chime I wouldn't discount the option of coding mux like commands into moo, it'd make it a lot easier for people who are used to that code to jump into the game and get involved. If the commands aren't what people are used to they tend to simply walk away.

Or make a really solid tutorial so that people can get the information on how to use the code upfront

When I helped run MOO games, we always aliased anything we could to MUSH or MUX (or both) commands. People seemed to appreciate it, and it took us very little effort.

The big hang-up in MOO for players was always @mail and the concept of mailers rather than bboards. I always really preferred it (noteditor so dang powerful), but others found it really frustrating.

RnMissionRun

@Chime said in Chime's MOO thread:

I'll have to take a look. I think the WAIF type is similar in utility, but if hellmoo's dictionaries are more robust then by all means.

WAIFs and dictionaries are different things. A dictionary is a hash map:

this.cg_stats = ["int" -> 10, "dex" -> 12];
this.cg_stats["dex"] = 8;

A WAIF is a type of "lightweight object". It's essentially a list of data that is able to masquerade as a "real" MOO object in some situations. They can even contain verbs and properties, just like a real object. WAIFs are useful because they help keep object numbers down, they make for a much less spammy @audit, and they save a bit of RAM. They're also much more trivial to create/destroy than "real" MOO objects. They're quite useful for virtual inventory systems, weapons, clothing, even use them for exits to replace the default MOO $exit object parent.

Cold has dictionaries also but the syntax is different:

my_dict = #[['one, 1], ['two, 2], ["seventy", 70]];

Cold also has something similar to WAIFs called a "frob".

RnMissionRun

If you're serious about working with MOO, I strongly urge you to go to http://www.vmoo.com/en/download/ and download the VMOO client. Once you've installed it, log on to the MOO and type:

@edit-options +local

This will enable local editor support on the MOO. What that means is, anything you attempt to edit on the game, including programs, mails and descriptions, will be shipped to your client for editing in the builtin text editor with syntax highlighting and other handy features. Once you've finished editing you just click a button to ship the text back to the MOO. The text in the editor windows remains until you close the window, so you can keep editing even after sending the text back to the MOO (You most definitely won't want to do this with mails though because each time you send the text back to the MOO, it will mail another copy). You can have multiple editor sessions open simultaneously, and you can continue to use the MOO normally because you no longer get teleported to the editor room. Once you get used to using it, you'll wonder how you ever lived without it!

If you need to disable it for some reason, just type:

@edit-o -local

This app works fine on MacOS and LInux under WINE, but you do have to install mfc42 using winetricks or whatever.

Chime

@RnMissionRun said in Chime's MOO thread:

WAIFs and dictionaries are different things. A dictionary is a hash map:
A WAIF is a type of "lightweight object".

Last time I'd poked at this, objects were the "normal" way of getting dictionary type behavior-- using properties on some object that is, generally with a _ in front of each key.

This looks much better.

They're quite useful for virtual inventory systems, weapons, clothing, even use them for exits to replace the default MOO $exit object parent.

* supervillain laughter *

That looks magnificent.

If you're serious about working with MOO, I strongly urge you to go to http://www.vmoo.com/en/download/ and download the VMOO client. Once you've installed it, log on to the MOO and type:

Awkwardly, when I first switched to UNIX in 1995 they plunked me down in front of a DECstation 5000/25 with D|I|G|I|T|A|L UNIX and emacs 18. Well, vi was there too, but it was vi, not vim. So I've been an emacs user ever since, and I'm quite comfortable writing complex interactive elisp.

This will enable local editor support on the MOO.

We are in complete agreement that this is a mandatory feature, as well as all of the syntax highlighting, indentation, on-the-fly lint, context-sensitive language/api help, and automated structural editing and refactoring tools.

Preacher, meet choir.

This app works fine on MacOS and LInux under WINE, but you do have to install mfc42 using winetricks or whatever.

I've used emacs on Ultrix, IRIX, Solaris, HP-UX, MacOS X, Windows 9x and NT relatives, and... uh, ITS on PDP-10. Skipped the VAXen, for now. ... I will stick with emacs, for now.

This is all very good info about workflow expectations in existing MOO users though. Thank you.

RnMissionRun

@Chime said in Chime's MOO thread:

... I will stick with emacs, for now.

Are you familiar with RMOO?
Check out https://github.com/toddsundsted/rmoo

Chime

@RnMissionRun said in Chime's MOO thread:

Are you familiar with RMOO?
Check out https://github.com/toddsundsted/rmoo

I may need to adapt it a bit for the last six years of emacs changes, but this is... fantastic. Thank you!