09 Mar, 2009, Scandum wrote in the 121st comment:
Votes: 0
Rendelven said:
You may want to add that to the protocol so other people don't make the same mistake as I did.

I updated it and hopefully it's clearer now.

I also described the behavior in case of multiple variables more clearly, indicating that if a variable is send more than once the last reported value should be used as the default value, and that it's up to the crawler to decide how to process things. For example, if a mud reports PORT:23 PORT:80 PORT:4000 PORT:3000, the crawler could flag the mud as a port 23 and port 80 mud and overwriting the standard port whenever a port is reported, leaving 3000 since it's reported last.

David Haley said:
I would think that the term "Family" is a quite preferable.

With "FAMILY" I'd rather add the options: "DikuMUD" "LPMud" "TinyMUD" "MOO" "Custom" - to indicate generic ancestry. Not sure if MOO would fall under TinyMUD or not.

"maybe "DERIVED FROM" Would be a better variable name for direct ancestry?
09 Mar, 2009, David Haley wrote in the 122nd comment:
Votes: 0
'Derived from' works for me too, although it comes to mind that you need to figure out where to stop the derivation. I guess you would stop at the closest ancestor that is a publicly available codebase. (This is a problem for 'family' too – really it's a problem for the whole concept.)
09 Mar, 2009, kiasyn wrote in the 123rd comment:
Votes: 0
The MUDBytes crawler just uses a hash (uniquely keyed, multiple IP etc reports will be overwritten by the last one)
09 Mar, 2009, Scandum wrote in the 124th comment:
Votes: 0
It's a bit problematic. The "FAMILY" value should be as broad as possible, and "DERIVED FROM" should be the nearest public codebase. "CODEBASE" should be as narrow as possible and taken as is.

3 values might be a bit much to deal with for crawlers though. Maybe stick with FAMILY and CODEBASE ?
09 Mar, 2009, David Haley wrote in the 125th comment:
Votes: 0
Why would three values be too much? If they don't like one of them (presumably either 'family' or 'derived from', depending on what data they show the site visitors) they could just toss it.
09 Mar, 2009, kiasyn wrote in the 126th comment:
Votes: 0
I would prefer the protocol be changed for multiple responses to have a delimiter,

ie

IP 192.168.0.3, 202.61.98.2,
PORT 23, 18, 80, etc

otherwise storage dbwise etc is going to become a hassle for the crawler.
09 Mar, 2009, David Haley wrote in the 127th comment:
Votes: 0
Adding a delimiter makes the protocol a fair bit more complicated as you now have to deal with escaping the delimiter. Having repeated values means you need two passes on the response, but the protocol itself remains very simple. This is true with both subneg and text-based protocols.
09 Mar, 2009, kiasyn wrote in the 128th comment:
Votes: 0
Considering the protocol currently only has 2 values that can have multiple responses, and in neither of them is a comma a valid character that shouldn't be a problem.
10 Mar, 2009, David Haley wrote in the 129th comment:
Votes: 0
Seems like a pretty big limitation for such a very simple problem. The chances of sending listed string data are much higher than sending some kind of fully structured data (think list of online players), so it doesn't make much sense to me to cripple the data format just because crawler authors want a one-line solution.
10 Mar, 2009, Scandum wrote in the 130th comment:
Votes: 0
kiasyn said:
I would prefer the protocol be changed for multiple responses to have a delimiter,

otherwise storage dbwise etc is going to become a hassle for the crawler.

I'm not sure if it's smart to add hassle to every field to decrease the hassle of two fields. If you use a hash, wouldn't it be doable to add a counter to the hash data structure, and work the database accordingly?

Protocol wise I'm thinking of adding the field:

"FAMILY" with the following values "AberMUD", "CoffeeMUD", "DikuMUD", "LPMud", "MajorMUD", "MOO", "Mordor", "Rapture", "TinyMUD", and "Custom". I think that contains all the major families, did I miss any?

PREROGATIVE then can be dropped. That'll make that part of the naming work much like genre and subgenre currently do without adding too much variable bloat.
10 Mar, 2009, mtfox wrote in the 131st comment:
Votes: 0
Another I think a lot would want is PVP… FULL LIMITED NONE ?
10 Mar, 2009, quixadhal wrote in the 132nd comment:
Votes: 0
Scandum said:
kiasyn said:
I would prefer the protocol be changed for multiple responses to have a delimiter,
otherwise storage dbwise etc is going to become a hassle for the crawler.

I'm not sure if it's smart to add hassle to every field to decrease the hassle of two fields. If you use a hash, wouldn't it be doable to add a counter to the hash data structure, and work the database accordingly?


I'm sure kiasyn is using a perl/ruby hash, which isn't a hash table (well, it's implemented as such, underneath), but should really be called an associative array. As such, he'd have to re-engineer it to always have the key point to an array, rather than the simple structure you'd use if all your keys are unique.

As for it bogging down the protocol to have delimiters, I again mention that your protocol already has built-in assumptions about the fields it supports. IE: some fields are integers, some are strings, and the only way to know this is to read the description IN the spec. Likewise, there's no reason EVERY field has to support delimiters… it can be spelled out which do and which don't.
10 Mar, 2009, Scandum wrote in the 133rd comment:
Votes: 0
PVP is listed under Gameplay at the moment, so PK muds are covered. I'm afraid that adding a detailed setting would open a big can of worms, because then you'd have to add RP = NONE RPI ENCOURAGED ENFORCED, etc. Also keep in mind that many roleplay enforced muds are full pk muds as well, while they don't resemble your typical pk mud in the least bit.
10 Mar, 2009, Scandum wrote in the 134th comment:
Votes: 0
quixadhal said:
As for it bogging down the protocol to have delimiters, I again mention that your protocol already has built-in assumptions about the fields it supports. IE: some fields are integers, some are strings, and the only way to know this is to read the description IN the spec. Likewise, there's no reason EVERY field has to support delimiters… it can be spelled out which do and which don't.

All values are strings, though the crawler can decide to treat them as integers.
10 Mar, 2009, Scandum wrote in the 135th comment:
Votes: 0
I've given it some more thought Kiasyn, and would the following format work for you? MSSP_VAR "var" MSSP_VAL "val1" MSSP_VAL "val2" MSSP_VAR "etc"

Most important value should be reported last. As far as I can tell it's forward compatible with my implementation in tintin and mth. But if you can find a solid way to handle the protocol as currently defined that be preferable.
10 Mar, 2009, David Haley wrote in the 136th comment:
Votes: 0
Scandum said:
and should give the most distant generic codebase the mud is derived from, unless it's a custom codebase.

This is kind of confusing: it sounds like you mean the most distant ancestor. Did you mean the most distant ancestor, i.e. the earlier codebase, or the closest ancestor, i.e. the most recent public codebase?

Also, I would use a term other than "generic", such as "stock", "public", etc.
10 Mar, 2009, Scandum wrote in the 137th comment:
Votes: 0
Most distant ancestor, the actual protocol definition gives a limited list of common ancestors to pick from and doesn't define it.
10 Mar, 2009, quixadhal wrote in the 138th comment:
Votes: 0
The most distant ancestor would almost always be AberMUD, since LP, Diku, and Tiny all derived from it. The closest ancestor would be a more useful value, since one could see that AFKMUD is a Smaug derivative, which itself is a Merc derivative, which is a Diku derivative. Someone looking for a MUD to play would care about the difference between Smaug, ROM, Circle, etc… the fact that they're all Diku is almost irrelevant.
10 Mar, 2009, Scandum wrote in the 139th comment:
Votes: 0
quixadhal said:
The most distant ancestor would almost always be AberMUD, since LP, Diku, and Tiny all derived from it.

They were inspired by AberMUD, not derived from it. The only AberMUD derivative I know of is Dirt.

I'll leave it to the mud crawlers to translate the FAMILY and CODEBASE values into a hierarchical structure of derivatives.
10 Mar, 2009, David Haley wrote in the 140th comment:
Votes: 0
I don't think this is an instance where trusting the crawlers to do the right thing is appropriate. If the protocol is going to provide data that is supposed to fit into some structure, it should say what that structure is. Otherwise, if data is provided in isolation, it's not terribly useful.
120.0/154