mudmixer
rmoo
| mudmixer | rmoo | |
|---|---|---|
| 2 | 2 | |
| 0 | 8 | |
| - | - | |
| 2.7 | 1.8 | |
| about 3 years ago | 9 months ago | |
| JavaScript | Emacs Lisp | |
| MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mudmixer
-
Show HN: I rewrote the 1990's LambdaMOO server from scratch
https://web.archive.org/web/20201203080354/http://www.vmoo.c...
Looks like the VMoo website is still there but is having... issues. But this is the last release. If you have a high DPI display you may find it slightly lacking, even with Windows compatibility settings applied. Which is a shame because VMoo was always the best client.
Most GUI-users use Mudlet (https://www.mudlet.org/) these days. Unfortunately, as far as I know, it lacks proper local editing support. If you're feeling adventurous you can work around that with something like MUDMixer (https://github.com/tms88/mudmixer) to proxy local editing.
-
Do all muds use insecure connections?
If sci-fi is your thing, Prometheus and Miriani both offer ssl/tls on ports 7777 and 1444 I think) respectively. If your client doesn't support tls/ssl, might I suggest mud mixer. Found at: https://github.com/tms88/mudmixer It supports connecting over tls, as well as a bunch of other features that you may or may not find useful.
rmoo
-
Show HN: I rewrote the 1990's LambdaMOO server from scratch
I've done the "whole new thing" before, too. 20ish years ago, tho I only have a few fragments of what I worked on back then: https://github.com/rdaum/mica being one of them I found on an old drive. Not complete.
But sticking with compatibility has allowed me to enforce development discipline, basically. And then I'll move it onwards from there.
Re: world state / transactions -- yeah, basically all I/O and mutations happen in a transactional context, and then at commit time conflicts are resolved; if they're not resolve-able, the transaction is retried in a new state. As for overhead, yes potentially maybe a lot, but it's also a solvable problem; this is how an MVCC SQL database (like, even Postgres) works. TLDR it's likely inefficient now, but I believe I can make it efficient. And I think it's the best to solve the shared world state problem and still meet user's expectations of consistency.
Re: the MOO client, it's `rmoo.el`: https://github.com/lisdude/rmoo -- it's been around for a long time (25, 30 years?) and it and/or MOO.el (another emacs one) are how/why I learned emacs in the first place. I had to patch my local copy to make it work with emacs 29.1.
-
1980: MUD
A friend of mine maintains a fork of RMOO, an Emacs MOO/MUD client. You might find it interesting: https://github.com/lisdude/rmoo
What are some alternatives?
tinyfugue - TinyFugue - Rebirth
toaststunt - A network accessible, multi-user, programmable, interactive system for the creation of MOOs / MUDs.
mica
nmoo - An enhanced LambdaMOO-like MOO
fastglobal - Fast no copy globals for Elixir & Erlang.
moor - A rewrite of the classic LambdaMOO server; but in Rust and on a modern tech stack
EtaMOO - A new implementation of the LambdaMOO server