I'm having trouble connecting, or everything's gray, or when I connect I see only black or flickering, or I have some other problem.
See Bugs and Troubleshooting.
Do you have an ehMOO server running that I can connect to to try things out?
Neither of us have the time or resources to run our own ehMOO, but we'll add a page listing known servers if there's any interest in that. To try things out without running a full-fledged ehMOO of your own, set up your own local miniMOO and connect to that as described on the ehMOO website.
What's really needed is a 'spy' type program that dynamically tracks the presence of ehMOO/miniMOO servers, along with some client code that automates enabling/disabling portals and making connections to servers present in the list.
Why not just use VRML as the world format?
A couple of reasons. First, VRML and its renderers are overly complex for our purposes. Secondly, they're too slow. A full-blown VRML renderer will never be as fast as a raycasting engine.
You guys have been working on this a long time. What took so long?
Well, here's a brief history of the project. Way back in 1995, we had grandiose plans of creating a multi-player gaming experience of hitherto unparalleled richness and complexity, which could also be used as a basis for ongoing experimentation with a whole host of cutting-edge technologies. We quickly had a version of a pretty good (at the time) raycasting engine (wt by Chris Laurel) modified to dynamically accept and display room descriptions and some LambdaMOO hacks that would drive the creation of those rooms (corresponding to MOO rooms) on the wt client. Encouraged by our early and very quick success with that prototype, we formalized a protocol and went to work implementing it. We had things basically working fairly quickly, so we expanded the protocol, and had more things working, somewhat quickly. Meanwhile, we decided we needed some editors to make things easier, and needed to add some bells and whistles to the client and likewise on the server, and got these working none too quickly. Somewhere in the 'none too quickly' phase, we entered a 'not very quickly at all' period which could be measured in units of years, characterized mainly by our not thinking about the project at all, much less working on it. A perfect example of the consequences of violating the cardinal rule of open source development - 'release early and release often'. But we were still on the MOO-Cows and MUD_DEV mailing lists and from time to time would still see discussions of ASCII interfaces and protocols to render ASCII representations of worlds and other discussions of graphical vs. text MUDS (ehMOO attempts to do both justice), etc. and one of us was also sort of following the technical side of things like messaging and the peer-to-peer craze e.g. Jabber and being a bit bored and seeing the possibilities of a truly peer-to-peer 3-D virtual reality, decided to quickly whip up a simple one-room subset of ehMOO written in Java (miniMOO). Some other promising projects intervened, and we set aside even miniMOO for a time, but again came back to it after realizing that it might still be relevant, and not wanting to throw a lot of work out the window forever, we decided to finally get it all together, document and release it, which is where we are today. We think it still has a lot of potential, but frankly we need to get other people interested in updating and extending it if it's to go anywhere but back on our shelf. In the worst case, we're hoping it might be of some interest to hackers or students interested in the problem of unobtrusively supplementing text-based MOOs or MUDs with graphics capabilities. By the way, the name ehMOO come from the original name of our expansive project, eh, which stands for Event Horizons. We discovered too late that both the company and domain name were already taken, but it still works for us, since one of us is a Canuck.
What's the future of the ehMOO project?
It depends mainly on whether or not other developers are interested in working on the code and tools. Both of us are pretty burned-out on the implementation of the graphics protocol, which includes both client and MOO server and moocode coding, though Steve is still interested in the protocol design and 'actor languages' in general, of which gprot is an example. We're also none too interested in any more tool coding e.g. ehed, objed, so both of these areas we're more than willing to hand over to anyone who's willing and able. In our own words, here's what we're each interested in. Please contact us if you'd be interested in working with us on any of these topics:
Tom:
Steve:
How do the graphical connections actually work, from a MOO perspective?
Graphics connections are actually players with negative numbers i.e.
guests associated with the real text player (who might not be connected
textually). The text character's password is necessary to get a graphics
connnection. When a graphics player (negative numbered) graphically moves to another room, the text player is moved to that MOO room, and when a text player moves to another room e.g. @move me to "the conservatory", the graphics player is moved to a graphical position in the MOO room.
How stable/secure is ehMOO?
We're not expert server or moocode hackers, and this is beta quality software, so until someone who is an expert can sign off on this code, which may never happen, we can't guarantee that you won't get server crashes or see security problems in the moocode - we've had the server running for extended periods, albeit with not much traffic, and haven't seen any crashing problems, but that doesn't mean it can't happen. As for the moocode, well, we're just not confident in our moocode coding abilities, and it would be very easy for us to miss subtle or not so subtle problems in the moocode we've written. It works for the purpose it was intended, but we can't claim that it won't have problems. The server patches are unlikely to be the cause of security problems, but we can't claim confidence that the moocode won't. We'd welcome any moocode expert's perusal and/or patches.