25 Mar, 2009, David Haley wrote in the 222nd comment:
Scandum said:
David Haley's Momma is what'll stop you, be afraid, very afraid.
It's interesting to see that your argument is reduced to blatant, stupid personal crap like the above.
25 Mar, 2009, Cratylus wrote in the 223rd comment:
Scandum said:
David Haley's Momma is what'll stop you, be afraid, very afraid.
Shigs said:
For that matter whats to stop me having Players: 500, Unique Players: 500?
David Haley's Momma is what'll stop you, be afraid, very afraid.
Whatever you're doing, it's not constructive for MSSP and it's not helping you.
-Crat
http://lpmuds.net
25 Mar, 2009, KaVir wrote in the 224th comment:
Shigs said:
Whats to stop me falsefying both fields?
That's up to the mud listing sites to deal with.
25 Mar, 2009, Guest wrote in the 225th comment:
KaVir said:
I'm not aware of any which require you to list the player count based on the number of unique IP addresses. So who's going to audit the MUDs that refuse? And how can you audit something like that anyway?
Nobody. Because I'm proposing we not waste time on this whole "unique IP" silliness. It's unverifiable without either strongarming the admins into giving the information, or logging in a ton of alts to see if the number of players based on that changes. And if none of the current listing sites care, why should the protocol?
Quote
Auditing the playerbase for TMC is fairly simple right now. You connect to the MUD, type 'who', and if the number of players is below the average given on their MUD listing you have a potential problem. You then check back twice more, and if the number of players is still below the average on both occasions, their listing needs to be updated.
And why can't the same sort of manual audit be done to verify MSSP player counts? Listing says you have 800 players. You log on 4 times at random and only see 8. They're inflating the data. Simple. You do whatever gets done to falsified listings if the site cares. If they don't, then I could manually enter data through a web form and arrive at the same conclusion.
Scandum said:
Alright, how about two variables: "PLAYERS" and "UNIQUE PLAYERS" - the last one having an IP requirement.
Or, how about dropping the IP crap completely? There's no reasonable way to verify it, so why bother?
25 Mar, 2009, Scandum wrote in the 226th comment:
Samson said:
Or, how about dropping the IP crap completely? There's no reasonable way to verify it, so why bother?
It's dropped from the official variable list.
26 Mar, 2009, Scandum wrote in the 227th comment:
Some updates to the spec page:
http://tintin.sourceforge.net/mssp
Added sandstorm.arthmoor.com:9696 to the crawler.
Changed PLAYERS variable's description to:
Removed the following variables:
These fields are still listed at the freely edible MudBytes article:
http://www.mudbytes.net/index.php?a=arti...
Also listing telnet and plaintext servers separately in case a crawler wants to debug plaintext servers, currently only godwars.org supports it.
http://tintin.sourceforge.net/mssp
Added sandstorm.arthmoor.com:9696 to the crawler.
Changed PLAYERS variable's description to:
"PLAYERS" Current number of logged in players.
Removed the following variables:
"MUDPROGS" Current number of mud program lines.
"MUDTRIGS" Current number of mud program triggers.
"RESETS" Current number of resets.
"SSL" SSL port, use "0" if not supported.
These fields are still listed at the freely edible MudBytes article:
http://www.mudbytes.net/index.php?a=arti...
Also listing telnet and plaintext servers separately in case a crawler wants to debug plaintext servers, currently only godwars.org supports it.
26 Mar, 2009, David Haley wrote in the 228th comment:
When did we decide to get rid of triggers and progs? Just because they don't apply to everything doesn't mean we can't leave them there with a N/A option for MUDs where it doesn't make sense.
26 Mar, 2009, Scandum wrote in the 229th comment:
David Haley said:
When did we decide to get rid of triggers and progs? Just because they don't apply to everything doesn't mean we can't leave them there with a N/A option for MUDs where it doesn't make sense.
There've been several complaints about trigs and progs, so as not to be called a dicktator, cancer, retard, etc, they're optional now.
As a side note, total of 42 official variables.
26 Mar, 2009, David Haley wrote in the 230th comment:
The complaints were that they're not applicable to all MUDs and weren't clearly marked as N/A being an option, nor was there a reasonable alternative for other MUDs to express interactivity. But I didn't think people were saying to get rid of them entirely.
26 Mar, 2009, Scandum wrote in the 231st comment:
David Haley said:
The complaints were that they're not applicable to all MUDs and weren't clearly marked as N/A being an option, nor was there a reasonable alternative for other MUDs to express interactivity. But I didn't think people were saying to get rid of them entirely.
They're still in the MSSP Fields article, so they haven't been gotten rid of entirely, and -1 has been a valid N/A option for numeric values for a week now.
26 Mar, 2009, David Haley wrote in the 232nd comment:
This distinction you are making between "official", "unofficial", "still in the MB article but not spec" is unclear to me. And I guess you decided that -1 was the most appropriate option even though there was disagreement about it.
02 Apr, 2009, Scandum wrote in the 233rd comment:
02 Apr, 2009, Scandum wrote in the 234th comment:
Updated my mssp crawler to report average players and uptime, mainly as a proof of concept.
03 Apr, 2009, elanthis wrote in the 235th comment:
Is that uptime in days, hours, or minutes? Looks good.
03 Apr, 2009, Scandum wrote in the 236th comment:
The uptime is in days. I think Godwars II saves the boot time during a copyover, so does Storms of Time, hence their inflated uptimes.
04 Apr, 2009, KaVir wrote in the 237th comment:
Scandum said:
The uptime is in days. I think Godwars II saves the boot time during a copyover, so does Storms of Time, hence their inflated uptimes.
You know I save it over reboots, because I specifically asked if that was permitted, and you said it was:
http://www.mudbytes.net/index.php?a=topi...
Scandum said:
If you can be bothered to add passing the previous boot time along to the new process, sure. Common sense applies I think.
KaVir said:
UPTIME: With an exec copyover/hotreboot the mud process restarts, but from a player's perspective the mud is never down (in fact, unless you explicitly tell your players that the mud has rebooted, they might not even notice). Should such a reboot reset the UPTIME?
If you can be bothered to add passing the previous boot time along to the new process, sure. Common sense applies I think.
04 Apr, 2009, Keberus wrote in the 238th comment:
UPTIME 28 Mar 2009 15:41:47
Wouldn't it make more sense to call the variable UPSINCE, maybe it's just me, but usually when I think of uptime I think of 10hrs or 150hrs, not a specific time.
04 Apr, 2009, Scandum wrote in the 239th comment:
Keberus said:
Wouldn't it make more sense to call the variable UPSINCE, maybe it's just me, but usually when I think of uptime I think of 10hrs or 150hrs, not a specific time.
UPTIME 28 Mar 2009 15:41:47
Wouldn't it make more sense to call the variable UPSINCE, maybe it's just me, but usually when I think of uptime I think of 10hrs or 150hrs, not a specific time.
Not necessarily because the variable is meant to communicate the uptime, and using a timestamp is the most efficient way to do so. My crawler page isn't dynamically generated, so that's why I settled for translating the timestamp to a readable date.
04 Apr, 2009, elanthis wrote in the 240th comment:
What's the period for the averages? last 30 days? last 7 days? I know you said it was just a proof of concept, but numbers are a bit useless without the information necessary to interpret them :)
For uptime, I'm not sure an average uptime is really meaningful anyway. If a MUD has rebooted once in the last 60 days, it essentially has the same total amount of running time as a MUD that didn't reboot at all, but that one reboot causes the average to be cut in half. (Hence why KaVir probably wants to save the uptime across reboots.)
More useful stats might be something like total running time in the last month (or total down time in the last month). That in turn is pretty much based on how often the crawler detects the MUD is down, not on any value the MUD itself can report. The crawler might attempt connections every 5 minutes but only try to pull MSSP data every few hours or something like that to get those kinds of stats.
I suppose even the player counts could be given a little more in depth treatment. It would be neat to know for example what time of day the player count peaks on average (is this a MUD where the playerbase is active at the some hours I plan on playing), what the average player counts are given times of day (a MUD might have an average of 10 players overall, but if there's 30 people on average on during 5-10pm my time, that's good to know), etc.
All issues for crawlers and their websites, not the protocol itself, of course.
For uptime, I'm not sure an average uptime is really meaningful anyway. If a MUD has rebooted once in the last 60 days, it essentially has the same total amount of running time as a MUD that didn't reboot at all, but that one reboot causes the average to be cut in half. (Hence why KaVir probably wants to save the uptime across reboots.)
More useful stats might be something like total running time in the last month (or total down time in the last month). That in turn is pretty much based on how often the crawler detects the MUD is down, not on any value the MUD itself can report. The crawler might attempt connections every 5 minutes but only try to pull MSSP data every few hours or something like that to get those kinds of stats.
I suppose even the player counts could be given a little more in depth treatment. It would be neat to know for example what time of day the player count peaks on average (is this a MUD where the playerbase is active at the some hours I plan on playing), what the average player counts are given times of day (a MUD might have an average of 10 players overall, but if there's 30 people on average on during 5-10pm my time, that's good to know), etc.
All issues for crawlers and their websites, not the protocol itself, of course.
You're appealing to some unknown authority again. It's well known that God is basically on my side. Seriously, drop it already.
I'm appealing to the "authority" of what everybody except you has been saying! I'm glad that we at least agree that you seem to consider yourself divinely appointed, with the divine power of knowing the Final Truth.