A directory of MU*'s that's actually good

Thenomain

@faraday said in A directory of MU*'s that's actually good:

@thenomain said in A directory of MU*'s that's actually good:

Out of technical ignorance I ask: Why not MSSP?

It's highly MUD-specific (number of rooms? PK-allowed? Classes? Races? Yeaaaah... not so useful for most MUSHes).

Isn't this what @sparks is proposing, tho? Something that is specific to Evennia and Ares? Or are we thinking about something that is more akin to UNIX finger or whois, which may have some required fields but any number of user-defined fields for what they think is important?

faraday

@thenomain Maybe I'm misunderstanding what @Sparks was getting at.

Ares and Evennia already have their own game lists and a means for populating them. I thought she was talking about something using MSSP. Evennia currently supports MSSP but Ares doesn't.

Thenomain

@faraday

I personally agree that if this is all MSSP can do then it should be ditched, but this is a server-level discussion that I should not be part of. I just fear the ol' XKCD "14 Competing Standards" issue. If what MSSP does could be folded into what some JSON report could do, then A+. Flexibility so that in 20 years when people say that Mu*s are dying we can expand it.

Alzie

@faraday I think you're misunderstanding what MSSP is. You can send whatever information you want over MSSP; it's a generic tag system. The only thing MSSP defines is the structure of the tags. For example, Giri currently sends the following out over MSSP:

ANSI:1
CODEBASE:PennMUSH 1.8.6p1
CONTACT:giri@vertinext.com
FAMILY:TinyMUD
HIRING STAFF:1
NAME:Giri
PLAYERS:0
PORT:6780
PUEBLO:0
UPTIME:11/18/17, 9:52 PM (43 days)
WEBSITE:https://giri.vertinext.com
XTERM 256 COLORS:1

faraday

@alzie Dunno. I've never heard of it before today. I'm just going off what the protocol documentation says. It defines a number of specific and optional tags with very specific meanings - most of which are utterly irrelevant to a MUSH. But even if it's generic it still doesn't change the other reasons I don't like it.

magee101

How did a question about finding games turn into codespeak? Games guys, games!

Griatch

@magee101 said in A directory of MU*'s that's actually good:

How did a question about finding games turn into codespeak? Games guys, games!

Because the "codespeak" concerns how to make such a list of games available.

As for MSSP, this is of course a very MUD-centric invention so the original specification lists things the listing-websites were interested in listing at the time of its inception. Until there is a central site that looks/lists other tags (or just lists all tags you provide) there is little point in expanding it with custom tags even though that's of course possible (it's a very straight forward telnet extension).
Having the game call the listing site (like Ares/Evennia handles its games) rather than the other way around appears to be a saner way to do it (the issue then rather becomes one of (lack of) ownership of your entry. With the Evennia listing site we have, for example, not introduced any registration concept yet, this is something we'll probably have to look into as the number of entries grows (the listing-site code is of course open-source though, so if anyone wants to make their own, feel free).
.
Griatch

magee101

@griatch So then shouldn't we rename this thread or something? I keep coming here hoping someone is going to actually publish a directory or list some game ideas.

faraday

@magee101 said in A directory of MU*'s that's actually good:

@griatch So then shouldn't we rename this thread or something? I keep coming here hoping someone is going to actually publish a directory or list some game ideas.

There is no such directory. The closest thing to a MU directory is the MSB ads thread. Talking about how to make a better directory seems eminently on-topic. But if the OP or a mod wants to rename the thread I don't really care.

Chime

@faraday MSSP can use either telnet IAC codes or a pre-login command. On MOOs we generally supported it with a pre-login command.

It'd be fairly straightforward to add to MUX, which has a reasonably nice telnet layer for these things but... eh, it's irrelevant for the mud-centric data and giving mudstats better data is largely pointless given it can do INFO.

Future work should probably be JSON-based and reasonably self-descriptive / general. I do like the idea of a game-to-game spidering protocol for distributed discovery and publication of games mirrored on each-and-every game. These days I'm more interested in getting Evennia to do do the things I want than adding features to mushes. I mean come ON people! Mushcode is terrible and needs to die out.

faraday

@chime I can't find anything about the pre-login command in the spec. Where's the info on that? Do Penn and Tiny support it?

Lotherio

@faraday

PennMUSH ...

INFO

This command returns some information about the MUSH you are on,
such as its version number, time of last restart, number of players
currently connected, and size of database. It can be issued from the
connect screen.

MSSP-REQUEST

This socket command shows some basic information about the MUSH, along with
any admin-defined information specified in mush.cnf with the 'mssp' option.
The info is also shown via the MSSP telnet option. Useful for MUD crawlers
and bots. For more information about the MUD Server Status Protocol (MSSP),
see http://tintin.sourceforge.net/mssp/

See also: INFO

Chime

@faraday, per http://tintin.sourceforge.net/mssp/news.php:

Mar 20, 2009 - Plaintext version of MSSP finalized and added to specification.

The mudbytes spec seems to be dead, and their wiki reports 500, so... hm. That was the only version that described the plaintext one apparently. Tintin's is incomplete because they only care about telnet.

A few code references (especially for MOOs) demonstrate the basic idea though; see https://thejoyofstick.com/blog/2012/05/12/share-your-moo-status-using-mssp/ for example.

This is largely representative of the overall state of decay in the MU* community. As telnet gets further phased out and web-clients start to take over, this is all going to be JSON-rpc and RESTful gubbish.

faraday

@chime Yeah I was just trying to determine what the command and expected output were if you issued that command on penn or tiny, since any hypothetical MUSH list wouldn’t be complete without including them. It’s it like we can reasonably expect Penn to respond to a Rest request.

Chime

@faraday, on SurfaceTension (a BluePlanet MOO that got delayed when various friends pulled me away to work on The Reach):

#7:2
":MSSP-REQUEST";
":";
":Provides in-band access to Mud Server Status Protocol (MSSP) data.";
try
  set_connection_option(player, "binary", 1);
  notify(player, "~0D~0AMSSP-REPLY-START~0D~0A");
  for var in ($mssp_data())
    notify(player, $list:join("~09", @var) + "~0D~0A");
  endfor
  notify(player, "MSSP-REPLY-END~0D~0A");
finally
  set_connection_option(player, "binary", 0);
endtry
return $nothing;
.

and then $mssp_data() was

#0:7
dbsize = 0;
helpfiles = 0;
rooms = 0;
exits = 0;
descs = 0;
progs = 0;
triggers = 0;
for o in [#0..max_object()]
  if (valid(o))
    dbsize = dbsize + 1;
    if ("description" in properties(o))
      descs = descs + 1;
    endif
    if (parent(o) in {#17, #18})
      rooms = rooms + 1;
    endif
    vind = 1;
    for v in (verbs(o))
      progs = progs + 1;
      if (verb_args(o, vind) != $tnt)
        triggers = triggers + 1;
        while (tpos = index(v, " "))
          v = v[tpos + 1..$];
          triggers = triggers + 1;
        endwhile
      endif
      vind = vind + 1;
    endfor
  endif
endfor
return {{"NAME", "SurfaceTension"}, {"PLAYERS", tostr(length(connected_players()))}, {"UPTIME", tostr($boot_time)}, {"CRAWL DELAY", "1"}, {"HOSTNAME", "surfacetension.accela.net"}, {"PORT", "7777"}, {"CODEBASE", "LambdaMOO 1.8.2-cvs20050209-5"}, {"CONTACT", "surfacetension-mssp-1@accela.net"}, {"CREATED", "2009"}, {"IP", "66.220.1.33"}, {"LANGUAGE", "English"}, {"LOCATION", "United States"}, {"MINIMUM AGE", "18"}, {"WEBSITE", "http://surfacetension.accela.net/"}, {"FAMILY", "MOO"}, {"GENRE", "Science Fiction"}, {"GAMEPLAY", "Roleplaying"}, {"STATUS", "Alpha"}, {"GAMESYSTEM", "Synergy"}, {"SUBGENRE", "Blue Planet"}, {"HELPFILES", tostr(helpfiles)}, {"ROOMS", tostr(rooms)}, {"ANSI", "1"}, {"VT100", "1"}, {"DBSIZE", tostr(dbsize)}, {"EXITS", tostr(exits)}, {"EXTRA DESCRIPTIONS", tostr(descs)}, {"MUDPROGS", tostr(progs)}, {"MUDTRIGS", tostr(triggers)}, {"ADULT MATERIAL", "0"}, {"MULTIPLAYING", "Restricted"}, {"PLAYERKILLING", "Restricted"}, {"QUEST SYSTEM", "None"}, {"Roleplaying", "Enforced"}, {"WORLD ORIGINALITY", "Mostly Stock"}, {"SSL", "0"}, {"ZMP", "0"}};
.

In summary:

MSSP-REPLY-START
(lines of tab-separated key-value pairs)
MSSP-REPLY-END

With CRLF line terminators.

The above code is wonky garbage and e.g. always returns zero exits as I never got around to making exits for that moocore. Yes, really. ._.

We should probably type this up into a revised spec, if the odd case anyone still cares about mssp...