Not trying to be a little kid, I'd just rather leave it to TMC to sort that shit out.

If people are interested in a community effort to create a list of 'unofficial' variables I'd be happy to link to the outcome.

Maybe Kavir is interested in organizing the effort, his past suggestions have been pretty useful to me, and he appears to be mentally stable, unlike most of us.

Why should something that affects the whole community be left up to TMC to decide?

Do we even know for sure that TMC will use MSSP?

Even if Icculus does decide to use it, I can tell you right now that TMC will ignore the PAY FOR PERKS variable - and the same is true for TMS. They will probably ignore several of the others as well, perhaps even all three of the required variables.

Likewise, there are certain variables that both TMC and TMS need which aren't covered by the protocol, such as "Quests", "Clans", "Multiplaying", "Playerkilling", "Equipment saves on exit", etc. Any MUD wishing to be listed on TMC or TMS will need to add those variables - and I'd say the majority of active MUDs are listed on at least one of those listing sites, if not both.

So right now I'm having trouble seeing the difference between the "official" and "unofficial" variables, considering that many official ones will be unused by most MUD listings, while many unofficial ones will be required.

I just hope that TMC and TMS will work together on the names of their unofficial new variables, as I'd hate to see "TMC-ROLEPLAYING: NONE, ACCEPTED, ENCOURAGED, ENFORCED" and "TMS-ROLEPLAYING: NONE, ACCEPTED, ENCOURAGED, MANDATORY" - or worse still, for both listing sites to require the "ROLEPLAYING" variable, but with different value names, effectively preventing a MUD from using MSSP with both sites.

Always in motion, the future is. "for sure", no, but he is definitely receptive,
assuming we get a standard people agree on. I've discussed it with him
through email.

-Crat
http://lpmuds.net

That'd be pretty annoying. The way I see it the currently defined set of variables is a small enough set to be inclusive to most Muds, especially the TinyMUD branch, and not be too big a burden on initial implementation.

Like I said, feel free to get started on a list of variables, and hopefully it'll be good enough for most Mud lists to want to use it.

I believe it'd be a lot easier if we had an official spec that covered as much as we thought we could, so that KaVir's problem is solved. He's right, really: if our spec doesn't cover fields that are currently in use, it has done a poor job of addressing its stated goal!

Furthermore, if we can cover the needs from the start, we reduce the risk of crawlers doing their own thing, but each doing it differently. Of course, we'll have to work with them, but I would recommend that we not do that until we've at least settled on something we think would make both of them work. The small set of "official" variables we have now is clearly not sufficient yet.

I'd suggest to just get started instead of arguing about futilities.

Concretely, what are you suggesting? Most people seem to be in agreement about the need for new fields. (where most == all - 1, as far as I can tell)

The biggest problem I see with that is that it's difficult for the crawler to determine if the banner has changed, though I guess this could be done by changing the filename.


What I already suggested, create a forum thread and appoint someone to update the consensus list of variables and their meaning.

Hi guys. I run one of the mud crawlers and I wanted to throw my two cents in. I should say first that I think MSSP is a great idea. Currently on the TinyMUD descendants (MUSH, MUX, MOO, MUCK) you can type 'WHO' or 'INFO' on the connection screen of almost all of them to retrieve connection stats, database size, and sometimes other information as well. It's in a format very similar to what MSSP currently uses. Compare this to 'hack and slash' games, where getting game information varies wildly from from game to game and is difficult to crawl without manual input. MSSP would bridge this gap.

Recently, somebody made this point:


I think the current 'PLAYERS' field specification should be reconsidered. Best case long term scenario: the majority of the MUD community adopts MSSP and then connection statistics could be universally based upon "actual" users and disregard multiplaying. Until this happens, however, games that implement MSSP in its current form are going to be at a disadvantage statistically compared to everything else. Some of the biggest MUDs on mudstats.com are pay-to-play MUDs that probably have no interest in adding support for community initiatives like MSSP. Realistically, how many muds that implement MSSP are just going to disregard the no duplicate IP rule and print out the number of connected players regardless? It's easier, and it makes them look bigger. I would currently choose to pull the 'who' count over a 'PLAYERS' field count if I had the choice just because so many other worlds don't filter out duplicate IPs. Either rethinking "PLAYERS", or having a "PLAYERS" and then a "UNIQUEPLAYERS" field might be a better way to go, at least until the point at which the majority of the mud community adopts MSSP.

Next, I think that a good number of the fields seem "hack-and-slash centric" – by hack-and-slash I mean game servers like Diku, Smaug, etc. Is this the intent of MSSP, or is it intended to be adopted by game servers outside of this realm? For instance, MUDPROGS, MUDTRIGS, MOBILES.. I think some of this stuff could be generalized so that MSSP could be more widely supported by other MU* servers. Are 'MOBILES' and the other specific object type fields really that much more useful than a general 'DBSIZE' field? Currently hundreds of MUSH, MUX, and MOOs provide a db 'size' statistic on their connection screens, without breaking it down into types (rooms, objects, exits, players). 'MOBILES' is hack-and-slash specific type, not found on MUX/MUCK/MUSE/MUCK/MOO, whereas 'DBSIZE' could be defined on all of them, and then used to compare the size of a Diku mud to a MUSH. I understand the fields are optional so MUDTRIGS and MOBILES could still be provided by games that had them, but it seems to me that the more general the fields are, the more widely supported MSSP will be, and the more useful to mud crawling sites.

In its current state I think MSSP will make the job of crawling muds much easier, but there is still a fair amount of manual work required by sites such as MUDConnector that rely on detailed world descriptions. Maybe this has already been discussed but I didn't see it.. what about a "DESCRIPTION" field? It would remove the burden of updating such game descriptions from the mud listing sites (via web form or email) and put it back on the game owners.

I also liked the idea of providing a list of players somewhere in the MSSP-REQUEST. This is less important but I can think of a few possible uses for this information.

All that said, MSSP is a good idea and I hope its final version succeeds and is widely adopted.

I have no objection to having a field along the lines of "DBSIZE" that some games would report as the sum of other fields, and other games would report as the main number.

(Is the concept of NPCs really that unique to "hack-and-slash"?)

In the tiny families (MUSH/MUX/MOO/MUCK/MUSE) an object is an object is an object. It could be programmed to act like an "NPC" but it's just an object as far as the server is concerned. The big difference is that there no built-in battle system, and most of these games don't use a battle system at all because they are based around role playing.

I see. So it's not that NPCs are a hack-and-slash concept, it's NPCs-who-do-battle. I was pretty surprised by your original phrasing, which is why I wanted to clarify that. :smile:

(Presumably at least some people are interested in what things "act like", not what they actually are in some server's internal representation.)

I'll take it up with TMC and TMS and see what they prefer - they've dealt with the whole unique mud voting mess and probably have a much better understanding of the willingness of muds to cheat. Keep in mind that if I drop the IP thing there is absolutely nothing listings can do about muds that log in 50 idling characters, which is trivial with most mud clients, and would make the potentially most useful MSSP variable worthless.


The term MOBILE originated with the original 1978 MUD. Anyways, can you specifically describe (or link to a source) what DBSIZE is understood to mean precisely?

My original goal was to make a very generic list of core variables, and link to an optional list maintained by TMC, or alternatively some list maintained by the community. The World category should probably be moved to the optional list if I replace it with DBSIZE, but as it is getting consensus is sometimes a very tedious process.

The field is simply called 'SIZE' in the INFO command on MUSH/MUX/MOO servers. It is the total number of database objects on a game (the combined number of exits, rooms, players, and objects). Example of the INFO display from the M*U*S*H connection screen:


The breakdown for this particular game is:


Garbage is just unused database space that has already been allocated. 'things' are synonymous with 'objects', which is I guess closest to what a 'mobile' is.



If a player connects 50 characters to a MUD and the admin do not approve, they'd quickly boot him. If they do approve, well that just means the admin are okay with cheating and they'd be willing to do so in other ways too, such as changing the MSSP-REQUEST code to output a higher number of players. That said, I do see validity in both methods which is why I suggested two fields.

Just my thoughts, I will end up working with whatever the final version is. Thanks for listening. :biggrin:

Are these object instances or prototypes? For example, if a mud loads 10 angry kobolds, should that count as 10 or 1 ?

Assuming it is prototypes, would a definition of DBSIZE as: The sum of all unique rooms, mobiles, and objects work? I'm not so sure if this would work all that well for non tiny muds.

Might be an idea to just get rid of "MUDPROGS", "MUDTRIGS", "RESETS" and "SSL" as official variables. Would it be very hard for Tinies to separately count items and mobiles?

Or just mark them as N/A when they're not appropriate, as several people have wanted to do so far…

How would this not work well for non-Tiny MUDs? My (Diku-derived) base already had in place lists of loaded objs/mobs and a separate list of the unique obj/mob/room/exit prototypes (indexes).

Most Muds don't have a garbage count, and tossing it all together doesn't make all that much sense to me.

Maybe redefine World to:

"AREAS"              Current number of areas, use "0" if area-less.
"ROOMS"              Current number of unique rooms, use "0" if roomless.
"CLASSES"            Number of player classes, use "0" if classless.
"LEVELS"             Number of player levels, use "0" if level-less.
"RACES"              Number of player races, use "0" if raceless.

And move the rest to the additional variable list.

That can be hard to determine on some of the MUSH's I've seen. Many of the MOO/MUSH/etc family of games are persistent worlds, and don't have such a thing as a prototype. Literally, you create a new object, and you assign whatever properties you need to it, attach any code to it you like, and away it goes…. Thus, it's far more likely that 10 angry kobolds would all be somewhat unique, beyond just what they're carrying.

By contrast, a Diku may have hundreds of instances of a kobold, but they will all behave exactly the same, and quite often even carry the exact same gear and loot.