To be fair, can YOU guarantee that whatever pre-existing library you're thinking of using will be available for every platform on which a MUD might be run? I'd hate to see folks who want to run games under OpenBSD, Solaris, or some future OS be left hanging because nobody wants to port a giant monolithic "standard format" library to their platform.

If the source to FooMarkup is available and brain-dead simple, it can be easily ported. If you choose YAML (for example), you place the burden of finding a working YAML parser on the end-user, and the API of said parser might be quite different from others that are held up as examples of how to add MSSP support.

I'm tempted to remind people of how we did things in the old days… delimited fields. What's wrong with sticking each field on a line with tabs between the field name and value(s)? Tough to parse (split in perl, explode in LPC or PHP, strtok in C), tough to generate (sprintf anyone?), no need for quotes around strings, can be hand-edited if need be. I'm not seeing a need for anything more than this. *shrug*

This is ridiculous. I hope your car has a harness for a jet engine, just in case you eventually decide to put wings on it.

I'm going to assume you merely misunderstood what I said. The whole point is that this language would not be extended, ever. If we ever decide to have more fields, it would be accomplished by changing the language to something more complex, when and if we need to.

With that, unless something new comes up on this particular subtopic, I'm done going in circles.

One last note: FWIW, I think Elanthis is right that a list is better represented as a series of key/val pairs with repeating key. Then the only parsing needed is a straight split on the colon. No escaping, either, except perhaps for newlines. (which I would recommend representing as a straight \n inside the data, and then let the consumer figure out how to represent it otherwise if they wish to)

Why not make it UTF8 compliant while at it?

Gee, that's brilliant. Now the MUD site will have to implement another parser in order to support both old and new versions of MSSP. Extensibility should be a goal, such that only the application need change if the data set changes, not the lower level functionality to access it. I really feel you just can't bear to concede, because you're not making any sound technical arguments.

Grimble, please don't try to psychoanalyse me. :smile:

You ninja'd me. :p

(yes, it really took over 40 minutes for me to write that. I was pretty blitzed last night. :p )



It was the announcement of the development of that game that ended up sealing the decision by our management to close our project, actually. They publically announced that game about 6 months after development started on ours, so we're not sure if they just had the same idea of ir one of our people (who were all under NDA) leaked. I'm more inclined to believe both our companies just had a good idea at about the same time. :)



A format like my proposal is already UTF8 compliant, unless you happen to use non-UTF8 data in your keys or values. You could just state that the data must be valid UTF8. However, keep in mind that using UTF8 inside of TELNET is a bit tricky if you're going to actually be compliant with the TELNET spec. You have to enable BINARY mode at the very least, and if the TELNET server/client have already negotiated a different encoding, spitting out UTF8 data in the middle of it could be pretty heinous. Then again, if your MUD isn't using just ASCII, it should already be enabling BINARY and it should probably just use UTF8 anyway, but I'm sure there are a ton of MUDs out there that spit out ISO-8859-1 or win-1252 without knowing any better.

Yeah, that always sucks. I had the same experience with Google News. Namely, one of my former bosses went out to Google and bragged about our product, and a couple months later, BAM! Google News appeared. It could have been coincidence, but I bet one of the PhD's out there said "Hey, I bet I could bang something like that out against our data store, gimme a couple of days."

:((((

Noooo me byootiful brackits!

Well, if that's what people want, that's fine…at least it won't make me physically cry like
implementing tab delimiters would.

-Crat
http://lpmuds.net

Yes, I know how you like to embed tabs in your mud name, player counts, and other statistical fields MSSP is supposed to provide. ;)

Well, I kind of prefer the bracket notation from some abstract correctness point, it's just that from a practical standpoint a series of values for the same "key" is really the same thing as a list for a given "key". Obviously this is different for more complex data structures, but just as obviously we can worry about that if and when we actually come to it – as we've amply agreed up to this point. :wink:

That's why I liked using tab delimiters. You just grab the whole line and do an explode() on it. The first entry is the key, any subsequent entries are values. So, you want a breakdown of classes available? Fine. "Classlist\tmage\twarrior\trogue\tcleric\r\n" Done. Can't get much simpler than that.

Theres any number of non-printable characters that can be used for that too, besides tabs. I always hate committing to brackets or semicolons out of some irrational fear that 'some day' I will want to transmit something with one of those characters, and then i'll have to worry about escaping them, etc.

Maybe we can put the format encoding debate to rest if we take a harder look at the data set and get consensus on that. In the "elite" :rolleyes: thread, I've pointed out that there are a lot of proposed variables (and I believe the floor is open to more or less of them) and some more thought should be given to what data is of interest and how will it be organized. For example, I can see…

universe:
    worlds   : 2
    areas    : 43
    rooms    : 3621
    mobiles  : 2310
    items    : 1965

…as well as…

universe:
    - world: overworld
        - area: stormy mountains
            desc   : blah blah blah
            rooms  : 84
            mobiles: 36
            items  : 22
        - area: barbary coast
            desc   : blah blah blah
            rooms  : 42
            mobiles: 10
            items  : 28
    - world: underworld
        - area: stygian abyss
            desc   : blah blah blah
            rooms  : 56
            mobiles: 13
            items  : 10
        - area: hades gate
            desc   : blah blah blah
            rooms  : 72
            mobiles: 26

Dikurivatives tend to toss non-printables from input, and I'm not sure if all clients accept them. Although I like tabs as a delimiter, you still would have to escape them in case you wanted to use them. In general, I think one should never assume "oh, we'll never use that…" unless it's easy to fix. Fortunately, a simple backslash escaping scheme is always easy to fix…

Anyhow the format:
Key1: K1Val1
Key1: K1Val2
Key2: K2Val1

is also very easy to parse, doesn't require escaping anything except the line-end delimiter, although you do have to put in several steps to get lists right. But since you need a step per line anyway, this isn't too onerous IMO.

Seriously, do we REALLY freaking care about data that complex? Honestly? Are you going to write a standardized Universe/World structure that all of 2 MUDs might end up using? Nobody cares about that level of detail. Nobody. It isn't useful to the end-users of this protocol, which is crawlers and MUD list sites.

You want arbitrarily complex data that can be formatted in arbitrary complex ways… why not just make a web page for your MUD and let Google crawl it? HTML and CSS can already do everything you're trying to do and an do it without anybody needing to write new code. Then you just need a simple way for a MUD crawler to find the web site for your MUD, and MUD list sites can just install Lucene or something to index them all.

I realize now I haven't even seen a rather key part to a MUD list crawler: how do these lists _find_ your MUD? You need to register your MUD… so you might as well just register an HTML page while you're at it.

Or a simple XML schema that is served from your MUD's website. In fact, there is already such a standard designed for similar use cases that is often extended for specific uses like this, called [url=
http://www.w3.org/RDF/]RDF! One file can be written and submitted to a MUD crawler that gives it your home page, player port, and all that random complex data you could ever want. You can EASILY make your MUD just spit out an RDF file every so often (you don't really need realtime stats because MUD crawler sites aren't going to connect to your MUD every time someone tries to view your MUD's sites – they're going to be caching the data anyway!).

STOP OVER-ENGINEERING.

I'm not sure if mud directories are in the mood to run two crawlers, one for muds, and another for their webspace.

My whole point, Scandum, was that you can just have ONE crawler that does both. There's a reason any games get by with just web pages, and there's a reason why RDF has become so popular for describing resources.

There are already many, many RDF extensions, including the software-related DOAP. Adding another extension for listing out general MUD and Diku-related MUD info would be simple.

All of these ideas about listing out universes and stuff is pointless, though. It's all very, very, very MUD-specific. I ran into a very similar problem with ZMP, where I was sitting down and trying to develop packages for advanced MUD features. What I realized was that almost everything interesting I wanted to do was far too specific to my MUD's design to be really reusable. The navigation system I want is unlike either Diku-based or geometrical MUDs. The damage system doesn't rely on hitpoint but on hit locations and detailed body location damages. Inventory is more complex than just what is held and what is worn and what's in the pack. The end result is that most of my packages would have been only useful to my MUD and, more importantly, that means that no clients would actually implement those packages except for my own.

It's the same deal with all these arbitrary data description things people bring up in this thread. Many of them are generic, yes, and many of them are related to the most popular MUDs (Diku-derivates), but many of them are very specific to certain MUDs and – this is the important part – every single crawler out there would just ignore all that data because it has no freaking clue what to do with it!

Just because you have well structured machine readable data doesn't mean that the machine understands what that data represents or how to use it. XML on its own is totally useless; it only becomes useful when both the producer and consumer of the XML are using a mutually-understood schema. The same is true for all other structured data formats, including YAML, JSON, S-Expressions, etc.

The only way to make a very application-specific schema general-purpose is to mix it with styling information so that the receiving machine can at least present it to a real user in an understandable format. If you're going to do thta, though, there is absolutely no reason to come up with a new format when we already have HTML and CSS. That's what those languages are for. A computer has no idea what all the information in a web page actually means, except for the styling information. It just lays out the data the way the HTML/CSS says it should and the user hopefully makes sense of that data. Crawlers then just index the words. That is the absolute best a crawler could do with weird MUD-specific structured data in MSSP, except that unlike HTML, the MUD listing site wouldn't have the information to nicely format and display all the MUD-specific information MSSP sent it.

Even with a simple key-value protocol, the entire protocol is useless if the crawler doesn't know what the keys and their corresponding values mean. You need a spec (which you have) stating what keys exist and what their values are. The spec can only hope to hold very generic information and perhaps the information common to 80% of MUDs, though. Trying to allow a ton of specialized information for non-standard MUDs just has absolutely no use, because the whole idea of a standard protocol is to allow many different implementations to access it… but those many different implementations aren't going to add code to actually process your MUD's custom structured data, so why bother supporting custom data in the first place? It won't ever be used.

It was an example, and only an example. The point I was making is let's take a step back and validate the proposed set of variables to date, which you are asking for as well. The intersection of data that is shared by a plurality of MUD servers may well be very small, but we may also find there is indeed a case for nested data because it's the is best way to model what we're interested in.