You could crawl in parallel…

As oenone suggested, you could crawl multiple muds in parallel.

Alternatively you could make the crawler smarter - build up a database of listings, only waiting a few seconds the first time you connect. Next time you visit that mud you can initiate the negotiation yourself, because you'll know the mud can handle it.

On the matter of crawling I added my mud here a day ago, I *think* I support mssp the right way using KaVir snippet, when am is uspposed to appear on your list Scandum ?
on http://tintin.sourceforge.net/mssp/mudli... there is no info on wich muds are parsed, or when it wil do it next.

only info is:MSSP statistics generated from 217.19.28.128 on 19 Jun 2011 22:39 UTC.

I crawl the muds listed on TMC about once a month.

Heh. I crawl MB once a day :P

Arcane Nites was added the 28th but it hasn't been added to mudbytes' MSSP list as of yet?

I ran Arcane Nites through my debugger.

1) The location should either be United States, Canada, or Mexico. North America isn't on the list linked by the spec.
2) FAMILY hasn't been set, this should be DikuMUD
3) GENRE, GAMEPLAY, GAMESYSTEM, STATUS, and SUBGENRE haven't been set. Information about these fields can be found at http://tintin.sourceforge.net/mssp

I've yet to fully automate the process, but MUDs will likely have to provide those variables for future inclusion.


The whole point of protocol is consistency. I'm sure you get the occasional request to add a pappa smurf and sponge bob that greet newbies and inform them about the joys of communism and homosexuality, upon which you no doubt politely remind them that consistency is the whole point of having a genre. I'm extremely uncomfortable with the idea of turning MSSP into a multiple-choice test for crawlers.

Ok will fix country, I did not looked at the spec while I was filling the values. BTW using String when you want a Constant value is (imho) a bad idea.
I would have used a numeric value and give relation table in the spec. (but thats me heh, I try to be at least as idiot as I am proof, and as you see when I am given String to fill that (should) be displayed as is, I dont check if values are forbidden)

Are there any other mandatory value than the one you listed ? Nothing in the spec says those values should be filled or otherwise the mud will be ignored.

It's difficult to keep the servers and crawlers synchronized. If I add Player vs Environment as a GAMEPLAY value it can be displayed as is with the current approach, where as with an index crawlers would display 11 or something. Also keep in mind MSSP was setup with the idea that mud lists with crawlers create their own extensions if needed.

All you need to do to be listed on the main page is to report the name, uptime, player total, and follow protocol. I was talking about the inclusion criteria for my crawler, it doesn't look all that great when most variables are left empty on the crawl report.

Consistency of data format, but MSSP was designed with the understanding that not all muds are implemented the same way. That's why it supports both negotiation and plaintext - indeed the specification itself explains that "Since it's not feasible for every mud to implement telopt negotiations a plaintext alternative is available". Likewise, it is not feasible for every mud to negotiate immediately on connection.

You've said your crawler is going to drop support for plaintext, and clearly it won't support muds that don't negotiate immediately - but that's only going to impact your own crawler, it's not a limitation of the specification itself. Other crawlers might choose to continue supporting plaintext, they might agree to wait a few seconds, and so on - indeed they may even extend the variable list. And those crawlers will produce larger and more detailed mud lists, making them more useful (and attractive) to players.


That would have the same problems I mentioned in the MTTS th...: It's not human readable, and it's harder to extend.

Matter of opinions, I think you made it too open for a protocol, but since I know nothing of the history behind it, I was just stating mine. I just know I never use String, and prefer Constants to avoid mistyping mainly, as sometimes I am easily distracted when I code either by alcohol or my current shitty life.
I also have a strong naming convention so I do not use a constant in a way it should not.

Off course that would force crawlers to always have the relation table up to date to see some of the newest value, but it seems to me to be a lesser evil. You picked a different poison than I would have chosen. At least without knowing all the reasons behind the choice.

I updated the value, I *think* I made it right. (thats why I asked if you had some script to automatically test all this) and I still did not find (without reading any help I admit) how to add a script in Tintin (either in linsux or winblows)

Not human readable, I concur.
Harder to extend as well if you use a bitvector I concur (you never know how many bit you really end up needing or wich bit etc)

But for keyname - value, no as if you want to extend it either you create a new keyname - value pair only your mud will use, and it is easy enough to refactor code nowadays to change it in case the spec decide to add it itself)

or you ask for a new value to be put in the spec.

For country I would not accept string as the value are quite finished //and it is the easy to add a new one fast enough
For language as well….

For genre, I would not force it to be anything and display whatever value is input.
Just opinions, so I will not argue more and go back coding :p

What do you have against using a string?

It's not just about bitvectors. As I mentioned in the post I just linked to:

What if Mudlet decided to use value 64 for extended ASCII, while MUSHclient simultaneously decided to use that same value for UTF-16, and both overlooked the fact that TinTin++ had already started using it a week earlier for a custom mud font? Worse still, because each new option is extending the specification rather than simply using it, you could end up with multiple conflicting specifications floating around the net.


As Scandum mentioned in post #28, "MSSP was setup with the idea that mud lists with crawlers create their own extensions if needed".

Let's take GENRE for example. Currently it lists the possibilities as: Adult, Fantasy, Historical, Horror, Modern, None and Science Fiction. Let's further suppose that instead of strings we were using numbers, so that None was 0, Adult 1, Fantasy 2, Historical 3, and so on. All well and good so far.

But now MudBytes decides to add the new extension 7, which is used for "Romance". At around the same time, The Mud Connector decides to add their own option 7 to cover "Western" muds, while Top Mud Sites starts using 7 for "War" muds.

That means that any mud using the value 7 will be listed as Romance, Western and War on three different listing sites - and (short of identifying the crawlers by IP address and customising the output) there's nothing they can do about it.

That is why I said to only use value where table are basically stable or VERY stable (like country or language) I fully agree otherwise. (Genre is definitely not stable)
The complain was about a country were I was directed to a table in the end anyway.

You'd have had to look it up if it was a magic number as well, to find out what value matched your country. So it wouldn't have saved you any time.

But it does mean that the results are human-readable. Anyone reading your MSSP fields will be able to see the country and language at a glance, without needing to look it up on some table.

@Rarva What problem are you solving by suggesting changing strings to integers? The obvious efficiency benefits are rather unneeded.

It is not about saving time, on the contrary even, but it is to enforce the 'right' value. With a number you are also forced up to look for that table if you want to set it. And if the crawler cannot find the value, I expect them to put 'invalid' in big red. Putting 'North America' in Red makes no real sense to me:
-it is a perfectly right value, it is even displayed ! Not even a typo !

I mean you have a table of some sort since you only take 0 or 1 for some other field..when it does not make more sense either as it limits the scope of it.

A protocol could be "present" 0 "not present" 1 'in developpement' 'in test' 'planned' etc…so you are already using tables in a sense for other fields.

Why not "true" and "false" ..that are way more readable in the first place than 0 and 1….

I don't know what you're talking about wrt what does and doesn't make sense. There's plenty of text protocols out there and it's not because some second rate developer designed them. It's because they have legitimate benefits as already mentioned in the thread. The only real argument I've ever seen made against it is the overall decrease in data transfered. Maybe you're objecting because you're used to dealing with something else, but "enforcing" values doesn't really add up since if you mess up a digit (5 instead of 6) you accidentally get a value you didn't mean without realizing it (like South America instead of North America), and being within the "enforced" system. That stands in stark contrast to your value being "North Ameica" in which it could either accept it heuristically or actually strictly enforce it.

Still a little more safe when you have to look into a table, you will probably copy paste the value instead of typing it.
Nothing is totally idiot proof, and I never claimed it was. But a ful blown text you will complain about is totally unrealistic. That is why you use a drop text selector for ages in a formular, and dont expect your user to type anything. It is a first layer that will need to be checked anyway, but it prevents most idiots to type something that does not make any sense.
That is my opinion, and you can have yours, and opinions are like assholes, eveyone has one. It is not meant to be the ultimate solution or one size fits all, it just my opinion on those kind of values n a protocol. I think those should be constants. Like it was decided for other field (0 1) Langage field has no iso table, should 'Gibberish' be allowed …
it is like gender, you use a numeric value, and not a string, so you can change male to man easily without changing anything else. It is data/view separation. More than that a numeric value can allow to change the langage it is displayed in. It is way easier to ask contry[value].french than parse the whole country[] table to find wich field is the right one.

MTTS will remain a central effort so there's not going to be any confusion over what field does what. If Mudlet, MUSHclient, or Bubba Mud want to have a field added they can shoot me an email, and with over 50 fields left I don't foresee any problems.