@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.