So far the mudbytes crawler just gathers any variables offered and chucks them in a database. it does no validation

Both TMS and TMC were positive and surprisingly didn't say anything negative about the variable set.

I really wanted to avoid creating the "Mud Server TMC Protocol", and keep the data footprint as small as possible - this so it can be used to frequently visit a mud to get the player and uptime count. I also wanted a different kind of categorization than has become the standard with TMC.

Variable wise a more thorough examination of the categorization section would be helpful. I'm wondering if someone could post the spec on Wora and see what the mushy people have to say about it?

Is the following clear enough? I know there've been objections, but this seems the only solution that's both practical and objective.

"PLAYERS"            Current number of logged in players. Multiple characters
                     with the same IP address must be counted as one.

Looks like my crawler correctly crawls telnet and plaintext MSSP, so let me know if you implement either one and want to be added.


Edit: While at it, should the return value -1 be added as to mean "N/A" for numeric values? I don't think there are any string values that would warrant this response as they should be left blank if not applicable.

I don't recommend a newbie do this. Maybe on the "mostly constructive" part,
but even then, I suggest an experienced WORA-er be the person to do it.

Electric Soup is a less vicious place for newcomers.

-Crat

I'm glad that you decided to completely ignore all objections, despite you being the only person defending this notion that one IP == one person.


No. Use N/A to mean N/A.

Re: using blank for string values.
This only makes sense if blank means "no value", not the silly notion "use previous value" – otherwise you're not being internally consistent in your suggested use of blanks.

I'm not defending the notion that one IP == one person, just trying to set something up that will be usable for competitive ranking.

Blank does mean "no value". Previous value only goes if you omit the variable entirely.

Regarding N/A: Maybe Kiasyn can give his opinion? I doubt N/A will store well in his database, assuming he stores rooms, resets, etc, as integers. Guess I'll ask Icculus as well.

You've already said that this can't be done correctly. Anything you do therefore will be wrong if you modify the data one way or the other. Present the facts, let crawlers or the humans reading the crawlers decide what the numbers mean.
Your ranking is not suitable for competitive ranking because, as we have said, it completely disfavors MUDs who have several people playing from behind one NAT. This is the case for my MUD, for instance, where we have some clusters of players from the same school.

Why do you need types at all? It's not like the crawler will be doing math on things. At worse, the crawler will have to coerce to integer – a trivial task (and sometimes even unnecessary depending on the language).

I'm currently reporting my player stats as anyone who is CON_PLAYING state. I'm not about to write up some logic to compare the whole loop of IPs for duplicates, sorry.

That's unfortunate, but otherwise it'll completely favor muds who allow people to idle 10 characters at once. I want to keep the data footprint small, so that means I'm not going to expect aardwolf to send over 500 player names and their ip address, that would be a pretty big privacy concern as well.


Same for coercing -1 to "N/A". I actually have no idea what the crawler might be doing with things.


Works for me, like with TMS it's probably not a big deal as long as you're a small fry or there's no massive multi-playing going on.

Well I should think that if Aardwolf sends a list of 500 player names that it's none of anyone's business what IPs those go to. That would be a humongous privacy issue. In some countries you can even get into trouble for giving that kind of data away to a 3rd party. Besides, we're not in a position to say that 500 players is a bogus figure. If that's what they report, that's what we should be listing. If people are found to be falsifying that data, we don't have to list them. So there's incentive to report accurate numbers.

No, because it will be indicated which MUDs allow multiplaying and which don't, therefore making it obvious to people which numbers they should take with a grain of salt. Who are you (or me) to decide which MUDs we favor?


You are committing a type theory error here: -1 is a number, not a lack of number. By saying that -1 means "no value", you're preventing any usage of -1 in the future. I don't mind if you do it on a per-field basis – indeed for some fields it makes no sense to have -1 as a value – but making it a general policy is a mistake.

How is that our business?

MSSP should report what it is told. Period. Starting to play number games with
mud admins will result in fail, pure and simple. Ask for a number of
users. Report the number. The end.

As for N/A, for heaven's sake. Srsly. What is the damage? There is a
huge difference between null, 0, -1, and does-not-apply.

Let's get something straight, folks. MSSP is going to be what the
end users and crawlers decide it will be, not what suits Scandum's
ideas of what mud ought/oughtn't do.

Scandum, wake up and learn cooperation. Please. There's no need
for each and every thing you dislike to turn into another MSSP plaintext
knock-down-drag-out.

-Crat
http://lpmuds.net

why not just a MULTIPLAY "0 or 1" flag and post that next to amount of players..??

That is a good idea for a listing key.

It does nothing for "resolving" the "problem" of liar muds.

At some point, muds will need to be judged by the community at
large about the truthfulness of their listing. The protocol should attempt
to play no role in that. The protocol is the medium, not the arbiter.

-Crat
http://lpmuds.net

And who are you to decide that multiplaying muds should be taken with a grain of salt? Not to mention that most multiplaying muds don't allow actual character cooperation making them (technically) no different from non multiplaying muds. Roughly 50% of the muds allow multi-playing, I think it helps that I'm not an active mud server developer and don't have my own mud's best interest in mind.


Agreed, should definitely be for positive integer fields.


Trying to play the crowd again? Keep in mind that I added plaintext because Icculus and Kiasyn both indicated they will support two interfaces, not because I'm a dictator who gets off on this shit.

-1, N/A, whatever, is pretty much up to Icculus and Kiasyn, no need to nag or rush it.

Oh, um, you mean like how you think that player counts on a multiplaying MUD aren't representative, and shouldn't be completely trusted. I guess I have to defend a position that you've stated as well?


I think this mostly means you just don't have a feel for what really happens in active MUDs. You go off talking about "fairness" but when somebody shows you something unfair, you brush it off as irrelevant and just personal interests.


Whaaaa? You mean it had nothing to do with the fact that basically everybody other than yourself preferred the plaintext version? :wink:

Ignoring the fairness issue for a moment, to the best of my knowledge none of the listing sites require you to take into account idle time or unique IP addresses in the playerbase size. That means MUD listing sites will favour muds that don't use MSSP, which is hardly an incentive for people to use it.

Wouldn't it be better to list total number of players, and then have a separate (optional) field for unique IP addresses?

I'm not sure how you'd quantify idling, but that again could be via another optional field.

mudbytes crawler stores all keys/values as text

whats the mssp text format being supported by mb?



or



?

neither atm, im too lazy / overworked.