http://tintin.sf.net/mssp/mudlist.json

As far as I know it's valid JSON. Not all fields are included, new ones can easily be added and included in the next crawl.

The PORT, INTERMUD, and FAMILY fields are stored as arrays, with the most important value first.

Awesome! Will plug it into my web app tomorrow.

Keep in mind that many MUDs don't report correct values, Bedlam included (invalid UPTIME).

For the sake of MSSP it might be beneficial to add a hint on the listing when values are not reported correctly.

Very nice. I'll also add that as a source for my mudlist generation thingy. :)

If I might make one suggestion, if you'd include a guarenteed key/value pair for ip-address, port, and name, in each record, that would make processing things simple and easy.

As it stands, the only reliable place to get connect info is by picking apart the mapping keys, which appear to be the hostname OR the ip-address, smashed together with the primary port number, and then having all periods replaced by underscores.

It would make for smoother processing if you could always rely on the keys "name", "ipaddress", and "primaryport" being present and populated, even if you have the server fudge it. :)

Agreed, I'll make sure to fill in HOST, IP, and PORT if not provided. Keep in mind that HOST can be an ip address.

Also keep in mind that an important aspect of MSSP is that when a MUD moves it can leave an old copy running on the old address, and forward crawlers to the new address by updating their MSSP fields. This can create problems when a MUD moves and forgets to update their MSSP entry.

So I'm thinking about adding CRAWLER HOST, CRAWLER IP, and CRAWLER PORT so mudlists can check if a submitted MUD reports a different host / port and subsequently report an error.

http://tintin.sf.net/mssp/mudlist.json

IP is now automatically set by the crawler.

The key of each MUD is now host:port with the host and port the crawler used to connect, values were pulled from TMC.

LAST HOST and LAST PORT have been added which hold the host and port the crawler used to connect. These can be compared to HOST and PORT, and I guess something needs to happen if they differ.

Awesome. Thanks Scandum!

LOL, now I just have to filter out ANSI escape sequences from the MUD NAME data, so my web page doesn't look extra-silly…

YES, I'm looking at YOU, idiot in charge of:

I could add a WARNINGS and ERRORS field containing an array of warning/error messages. I however refuse to automatically fix human error as a matter of principle.

How often does this get updated? I'm assuming it's statically generated since it's under SF.net.

hmm who colored the name of my mud.. ill get that sorted thanks for noticing…

Fixed… apologies for that appears that someone had changed the name of the colored mud name variable.. so now if that can be updated should all be sorted…

I didn't even know we reported anything (KaVir snippet) so I'm not surprised there were broken values. In honor of your efforts, I've attempted to fix the values :)

My snippet sets UPTIME the first time you call MSSPSetPlayers, which is covered in the installation instructions.

I didn't mean to imply that something was wrong with the snippet or the instructions. I just never got around to configuring that part until today.

I can upload updates to sourceforge automatically, but currently I'm starting the crawler manually. I plan to crawl every 11 hours, so a mud listing would probably want to update every 10 hours, which should be less bandwidth than performing the crawl themselves.

There's no real point in crawling regularly unless new MUDs can easily be added. So this would require people to put up a seed pages, a web accessible plain text file would work, hopefully something MudBytes and MudPortal can both do.

I can also crawl non-MSSP muds and provide some crude data, like supported telnet protocols, downtime, etc.