01 Jun, 2011, KaVir wrote in the 1st comment:
Votes: 0
The fields in the "Protocols" section are boolean, yet the protocols themselves can be utilised to varying degrees by different muds. So where exactly is the line drawn?

I think we can safely assume that the mud must both support and use the protocol to some extent in order to include it in their listing (eg it's not enough to just negotiate MXP, the mud should also make some use of it). But how much do you need to use it?

Is it enough just to have one clickable MXP link? Or (as in my case) if you make extensive use of clickable links, but don't use any of the other features, is that still sufficient?

Likewise with VT100, I provide an option for displaying energy bars using VT100 escape codes, but is that enough to quality for VT100 support? What about someone who just clears the screen?

Or UTF-8…I display gender symbols on the 'who' list and 'whois' display, but that's all (so far). Is that enough to let me fill in the field?

Or even ATCP - I use it I transmit MSDP data to clients that don't support MSDP. This is enough to do anything that you could also do with MSDP, but I don't actually support any of the official ATCP options.

There are an increasing number of muds adding protocol support, so I think it's worth reaching some agreement on this.
01 Jun, 2011, quixadhal wrote in the 2nd comment:
Votes: 0
If you use a VT100 escape sequence, you are assuming your client can understand and sensibly display it. If you use UTF-8, you are again assuming it doesn't come up as gibberish on the client's screen. In pretty much every case, before the server can safely use ANY part of any of those protocols, it has to have some reasonable expectation that the client can make sense of whatever is being used.

So, it's not so much a matter of "I support 25% of protocol FOO", as it is a "I'm going to use protocol FOO, so you better understand it or tell me not to." With that in mind, I don't think a list of "supported" protocols on a server makes much sense. Instead, it should be a list of protocols that are used, to whatever degree. One would almost call them required, but I suspect many could be negotiated and left disabled by default.
01 Jun, 2011, KaVir wrote in the 3rd comment:
Votes: 0
quixadhal said:
If you use a VT100 escape sequence, you are assuming your client can understand and sensibly display it. If you use UTF-8, you are again assuming it doesn't come up as gibberish on the client's screen. In pretty much every case, before the server can safely use ANY part of any of those protocols, it has to have some reasonable expectation that the client can make sense of whatever is being used.

Of course, that goes without saying. Either you automatically detect support for a particular protocol, or you ask the user to activate it manually.

quixadhal said:
So, it's not so much a matter of "I support 25% of protocol FOO", as it is a "I'm going to use protocol FOO, so you better understand it or tell me not to." With that in mind, I don't think a list of "supported" protocols on a server makes much sense. Instead, it should be a list of protocols that are used, to whatever degree.

Well yes, that's basically what I said in my post. My question was how much does the protocol need to be used in order to be included in the MSSP listing. Is it actually useful for prospective players when you mark the "VT100" field as true, if your only usage is clearing the screen before displaying the greeting, for example?

quixadhal said:
One would almost call them required, but I suspect many could be negotiated and left disabled by default.

They can all be either negotiated, or activated manually. The only one I assume support for is ANSI colour, but many muds prompt the user for that as well.
01 Jun, 2011, oenone wrote in the 4th comment:
Votes: 0
Maybe change the values from boolean to "mandatory", "optional", "automatic", and "not supported"?
01 Jun, 2011, KaVir wrote in the 5th comment:
Votes: 0
Quote
Maybe change the values from boolean to "mandatory", "optional", "automatic", and "not supported"?

There are already too many muds following the existing specification, it would be a pain to change the fields retroactively. But even if you did, the above proposal wouldn't solve anything.

I don't know of any muds that make any protocols (other than telnet itself) mandatory, unless they also require you to use their custom client (in which case the MSSP protocol fields serve no real purpose for that game anyway). Supported protocols are either detected automatically, or switched on by the player - but that depends on the protocol not the mud. MSDP is always detected automatically, for example, while ANSI colour is always handled manually, and so on.

So even with your proposed change, each protocol field would still only have two realistic possibilities.

However it still wouldn't address my question, which is how much does the protocol need to be used in order to be included in the MSSP listing. Is it sufficient just to say something like "The protocol must be both supported and usable by players", and then leave it to the individual mud owner's discretion as to whether they feel it's used significantly and constructively enough to select the MSSP field?
01 Jun, 2011, Scandum wrote in the 6th comment:
Votes: 0
MTTS tries to define some hard limits for ANSI and VT100 support client side. I personally define the use of custom scrolling regions as a requirement of a server side VT100 implementation.

The big downside of MSSP is that in practice 25% of the MUD servers do more or less whatever they feel like, it's their MUD after all, and if they feel the specification is lacking they'll happily improve upon it without bothering to write their own specification. I typically email once about obviously incorrect reports.

One current issue is that FluffOS reports an incorrect UPTIME (it reports time(NULL) * 10 rather than time(NULL) for the bootup timestamp), but I've been unable to figure out a way to contact the developers.
01 Jun, 2011, KaVir wrote in the 7th comment:
Votes: 0
Scandum said:
The big downside of MSSP is that in practice 25% of the MUD servers do more or less whatever they feel like, it's their MUD after all, and if they feel the specification is lacking they'll happily improve upon it without bothering to write their own specification.

I think clearer definitions in the specification could help reduce the number of accidental inaccuracies, but until some big mud lists start using (and filtering) the data it's inevitable that a few people will ignore the specification, or even lie about certain field entries.

Still no interest from TMC or TMS I take it?

Scandum said:
One current issue is that FluffOS reports an incorrect UPTIME (it reports time(NULL) * 10 rather than time(NULL) for the bootup timestamp), but I've been unable to figure out a way to contact the developers.

How odd. Any idea why?
01 Jun, 2011, Kaz wrote in the 8th comment:
Votes: 0
Scandum said:
MTTS tries to define some hard limits for ANSI and VT100 support client side. I personally define the use of custom scrolling regions as a requirement of a server side VT100 implementation.


That's really interesting. You've seen my little project, Scandum. I moved away from a scrolling-region approach to an approach where I completely control the client's display via ANSI/VT100 codes (indeed, I emulate the scrolling region for some parts). Would it not count?
01 Jun, 2011, duwnel wrote in the 9th comment:
Votes: 0
KaVir said:
The fields in the "Protocols" section are boolean, yet the protocols themselves can be utilised to varying degrees by different muds. So where exactly is the line drawn?


The problem with drawing lines in the sand is that they're easily trod over. Think of the option of listing protocols in boolean values as a warning, the way the boolean value of a grill switch can be taken as a warning that it is, indeed, hot (though not to what degree).

KaVir said:
I think we can safely assume that the mud must both support and use the protocol to some extent in order to include it in their listing (eg it's not enough to just negotiate MXP, the mud should also make some use of it). But how much do you need to use it?


Any use beyond basic negotiation should be sufficient, in this case. You're saying "I make use of this. Do you?" You're using that protocol generally to perform a function that can only be performed via that protocol, and that's enough. Further, just because you only use it for one thing now (UTF-8 Gender Symbols, for example), doesn't mean that you won't use it for more later. MU*s are in a constant state of flux, changing, growing, and adapting to the times.

Consider that you have incorporated MXP links, for instance. They're pervasive in your MUDs source code, but every telnet client connecting to your server doesn't support it. I know, this sounds ridiculous, but think back to pre-2002ish when MXP was just picking up support server-side, and zMud was still the original supporter. Whatever. While you offer support for the protocol, can you really be said to be making use of it?

KaVir said:
There are an increasing number of muds adding protocol support, so I think it's worth reaching some agreement on this.


Indeed it may well be. Those of you who do web design as well might notice how well that line of thinking has worked for HTML5 support (To recap for those of you unaware, it boils down to "If you don't do it my way, I'm taking all my toys and going home."). The problem is agreement, as well as the sheer volume of protocols popping up to support features. It's a constantly sliding scale, and the only way I can see to really approach it is in the way it's approached with browser compliance listings Either you support it, or you don't.

If you're really interested in taking this to some sort of conclusion, consider creating a MU* listing. Then, when an admin submits the MU*, a script runs server side (PHPs socket support is quite swanky) and connects to the game, and begins one-by-one testing and logging support of protocol features. Then automatically logs those features to the DB, and gives it a percentage score for incorporated support. Even if they only make use of a particular feature once, you'd still be aware of their ability to support that feature, and thus their potential to use it.
01 Jun, 2011, quixadhal wrote in the 10th comment:
Votes: 0
KaVir said:
quixadhal said:
So, it's not so much a matter of "I support 25% of protocol FOO", as it is a "I'm going to use protocol FOO, so you better understand it or tell me not to." With that in mind, I don't think a list of "supported" protocols on a server makes much sense. Instead, it should be a list of protocols that are used, to whatever degree.

Well yes, that's basically what I said in my post. My question was how much does the protocol need to be used in order to be included in the MSSP listing. Is it actually useful for prospective players when you mark the "VT100" field as true, if your only usage is clearing the screen before displaying the greeting, for example?

But why does it matter?

If you use *ANY* VT100 sequences, the client must support VT100 emulation. It makes no difference if it's just a single clear-screen sequence that's only in the greeting, or if the entire game is a roguelike that relies on full control of the terminal to work. If the MUD uses vt100 sequences at all, it should report that vt100 is used.

That was my entire point. The protocols listed shouldn't be some kind of soft and fuzzy "I kinda use this feature set" indication. They should be a list of requirements for the client. That way there is no ambiguity, and there's no question of what is and isn't supported. If somebody wants to try connecting to a MUD that says it uses MXP with a client that doesn't do it, they can… but they may not get all the content, or it may be unreadable. That's up to the server and what it chooses to do if it sees the client can't do something it wants to do.
01 Jun, 2011, Tyche wrote in the 11th comment:
Votes: 0
On an analogous note…
What if I list my gameplay as an RPI, but it has OOC channels and no staff?
How much is enough? ;-)
01 Jun, 2011, KaVir wrote in the 12th comment:
Votes: 0
quixadhal said:
But why does it matter?

To me? Because I support quite a few of those protocols to varying degrees.

quixadhal said:
If you use *ANY* VT100 sequences, the client must support VT100 emulation.

That's outside the scope of MSSP though. The server cannot use MSSP to find out anything about the client, nor is MSSP really intended to be used by a normal playing client.

quixadhal said:
The protocols listed shouldn't be some kind of soft and fuzzy "I kinda use this feature set" indication. They should be a list of requirements for the client.

I'm not sure they should. This is MSSP, remember - its purpose is to provide data to crawlers for populating mud lists, for helping players find games that match their personal criteria. It is specifically intended for indicating feature sets, and not for general use by clients.

From that perspective, is it actually constructive for a mud to claim support for a feature that it only supports in the most basic literal sense? If a player is looking for a game with VT100 support, is it useful for a mud list to recommend muds that only use VT100 to clear the login screen?
01 Jun, 2011, Scandum wrote in the 13th comment:
Votes: 0
KaVir said:
Still no interest from TMC or TMS I take it?

They've shown interest, but I guess they haven't found the time to set something up.

KaVir said:
How odd. Any idea why?

My best guess is they use a 10 beats per second heartbeat with a modified timestamp to allow decisecond event handling.


Kaz said:
That's really interesting. You've seen my little project, Scandum. I moved away from a scrolling-region approach to an approach where I completely control the client's display via ANSI/VT100 codes (indeed, I emulate the scrolling region for some parts). Would it not count?

VT100 mud clients will have a tough time dealing with your your emulated scrolling regions, but as you're still working with scrolling regions it'd classify as VT100 to me.

I think there are a few clients that have implemented the clear screen option, I think it's a weird argument to label that as VT100 support. I guess a mud could negotiate MXP, not do anything else, and label itself as an MXP capable MUD.
01 Jun, 2011, Tyche wrote in the 14th comment:
Votes: 0
How useful is it for players when a search for 'elves' at http://tintin.sourceforge.net/mssp/mudli... or http://www.mudbytes.net/index.php?a=mudl... turns up nothing?

On the latter I get about a dozen hits on info presumably not supplied via MSSP.
01 Jun, 2011, Scandum wrote in the 15th comment:
Votes: 0
Not overly useful if that's all you care about. I've thought about adding SCIENTIFIC RIGOR, HISTORICAL RIGOR to identify high/low fantasy and hard/soft fantasy. Low historical rigor would allow for the existence of elves, while soft fantasy would allow for elves with vast magical powers. Explaining the concepts would be tricky. Some kind of way to identify the era the game world is set in would be interesting as well.

As always self identification is tricky, but making people think about things like this would be the first step toward a deeper understanding and better use of categorization.
02 Jun, 2011, Tyche wrote in the 16th comment:
Votes: 0
Scandum said:
Not overly useful if that's all you care about. I've thought about adding SCIENTIFIC RIGOR, HISTORICAL RIGOR to identify high/low fantasy and hard/soft fantasy. Low historical rigor would allow for the existence of elves, while soft fantasy would allow for elves with vast magical powers. Explaining the concepts would be tricky. Some kind of way to identify the era the game world is set in would be interesting as well.


My point is that I think players are far more interested in gameplay styles (RPI) and thematic aspects (elves) than VT100 support.

Scandum said:
As always self identification is tricky, but making people think about things like this would be the first step toward a deeper understanding and better use of categorization.


Like MSSP, all mudlists I've seen rely on admin self-identification and categorization. I think it would more useful for them to be categorized by players.

Wouldn't it have been simpler to have made a PROTOCOL variable an array, rather than add new variables for every protocol?
How do you know that variables actually identify protocols and not something else? Should one use "VT220 Y" if one supports it?
02 Jun, 2011, Scandum wrote in the 17th comment:
Votes: 0
Tyche said:
My point is that I think players are far more interested in gameplay styles (RPI) and thematic aspects (elves) than VT100 support.

Possibly so. Still interesting to see which MUDs belief to have VT100 support.

Tyche said:
Like MSSP, all mudlists I've seen rely on admin self-identification and categorization. I think it would more useful for them to be categorized by players.

MSSP is still useful for player and uptime data. The idea of a player categorized MUD listing is interesting though.

Tyche said:
Wouldn't it have been simpler to have made a PROTOCOL variable an array, rather than add new variables for every protocol?
How do you know that variables actually identify protocols and not something else? Should one use "VT220 Y" if one supports it?

VT100 is pretty much the only standard (VT102 is pretty much identical) and due to the silly way termcap works most modern terminals self identify as xterm. From what I understand the VT220 has vector graphics support, but I've never seen it in action, but one would use "VT220 1" if one supports VT220 features.
02 Jun, 2011, Runter wrote in the 18th comment:
Votes: 0
I want IBM5100 emulation. So I can discover what CERN is up to.
0.0/18