14 Mar, 2009, Scandum wrote in the 41st comment:
Votes: 0
Ah ok, I linked gnome-mud in the article.
16 Mar, 2009, Scandum wrote in the 42nd comment:
Votes: 0
Added a dedicated web page for the protocol specs at: http://tintin.sourceforge.net/mssp.
16 Mar, 2009, kiasyn wrote in the 43rd comment:
Votes: 0
the kiasyn's crawler page is just a proof-of-concept for davion to base the mudbytes page off. it uses the mudbytes crawler data
16 Mar, 2009, Scandum wrote in the 44th comment:
Votes: 0
Ah ok, I'll rename it to MudBytes MUD crawler for now, and rename/link it to the MudBytes Mudlist when Davion gets around to updating the listing code.
16 Mar, 2009, hollis wrote in the 45th comment:
Votes: 0
There's a NakedMud module for MSSP support here. It requires a small change to input handling which will be part of version 3.8 (probably released next weekend). Proof of concept can be seen at my mud:

telnet://patrickmn.com:5000
16 Mar, 2009, Scandum wrote in the 46th comment:
Votes: 0
Updated the spec page with a link to nakedmud, and I assume you don't mind if I add Conquest to the crawler.

I noticed you gave the GAMEPLAY variable 3 values while you should only pick one. Player versus Player indicates a pure PK mud, Hack and Slash is your traditional mob slaying fest, and Adventure is for muds with a strong focus on non combat advancement and puzzle solving. The idea was to force muds into very broad groups based on the most dominant form of gameplay.
16 Mar, 2009, hollis wrote in the 47th comment:
Votes: 0
Scandum said:
Updated the spec page with a link to nakedmud, and I assume you don't mind if I add Conquest to the crawler.


Nope, don't mind.

Scandum said:
I noticed you gave the GAMEPLAY variable 3 values while you should only pick one. Player versus Player indicates a pure PK mud, Hack and Slash is your traditional mob slaying fest, and Adventure is for muds with a strong focus on non combat advancement and puzzle solving. The idea was to force muds into very broad groups based on the most dominant form of gameplay.


What if my mud is 33% PK, 33% Hack and Slash, and 33% puzzle solving? My game doesn't have a dominant gameplay. It requires all of these things in roughly equal proportions to succeed as a player. So should I say "Custom"? ;) The spec said:

Quote
The same variable can be send more than once with different values, in which case the last reported value should be used as the default value. It is up to the crawler to decide how to exactly process multiple values.


I'm fine with crawlers just looking at the last value, and have ordered them with that in mind. But I don't think what I am doing is contrary to the protocol, as defined? It's vague on this point, but I thought part of the purpose of allowing for multiple values was to accommodate these situations, and not just be intended specifically for port and intermud. If I'm wrong, might I suggest making use of the flexibility that exists? :)

p.s., tintin in debug telnet mode properly recognizes websites, but it looks like the crawler is setting them all to '0'.
16 Mar, 2009, Scandum wrote in the 48th comment:
Votes: 0
hollis said:
What if my mud is 33% PK, 33% Hack and Slash, and 33% puzzle solving? My game doesn't have a dominant gameplay. It requires all of these things in roughly equal proportions to succeed as a player. So should I say "Custom"? ;)

Adventure to a degree includes hack and slash as long as it doesn't dominate the game, and hack and slash includes optional PK. So it could be Adventure unless there is unrestricted PK which would make it a PK mud. It's a tricky situation, and I guess the mud lists will have the final say on it.

Quote
I'm fine with crawlers just looking at the last value, and have ordered them with that in mind. But I don't think what I am doing is contrary to the protocol, as defined? It's vague on this point, but I thought part of the purpose of allowing for multiple values was to accommodate these situations, and not just be intended specifically for port and intermud. If I'm wrong, might I suggest making use of the flexibility that exists? :)

It'll certainly allow mud lists to support multiple categories, but I personally think that'd be self defeating because many muds would list themselves as adventure, hack and slash, pk, roleplaying, and strategy, making it difficult to figure out what a particular mud's focus is.

Quote
p.s., tintin in debug telnet mode properly recognizes websites, but it looks like the crawler is setting them all to '0'.

It's caused by your mud reporting WEBSITE before NAME. I'll look into fixing it when I have time.
16 Mar, 2009, Zeno wrote in the 49th comment:
Votes: 0
Working on a patch to put MSSP in SmaugFUSS.
16 Mar, 2009, hollis wrote in the 50th comment:
Votes: 0
Scandum said:
It'll certainly allow mud lists to support multiple categories, but I personally think that'd be self defeating because many muds would list themselves as adventure, hack and slash, pk, roleplaying, and strategy, making it difficult to figure out what a particular mud's focus is.


If the crawler is for mud listing purposes, assume they are ordered by relevance. Yes, every admin will probably list all semi-relevant categories, but they'll have to make particular choices about how to order them based on who they want to appeal to. It's only self-defeating if you assume every item in the list has equal weight when searching for listings, but MSSP already specifies to put "the most important last". If the crawler is for something else (or doesn't want to support multiples) just ignore all but the last entry, as is already instructed to do.

errr… correction. It says put the default last. They're complimentary ideas, though, and it just kind of strikes me as functionality that should be capitalized on for mud listings.
16 Mar, 2009, Scandum wrote in the 51st comment:
Votes: 0
Zeno said:
Working on a patch to put MSSP in SmaugFUSS.

Totally sweet.

hollis said:
If the crawler is for something else (or doesn't want to support multiples) just ignore all but the last entry, as is already instructed to do.

Pretty much, it's fairly easy to keep overwriting the variable which results in the last reported value being used. Adding a FILO list for the other options should take care of the multi-option variables the listing wants to support.
16 Mar, 2009, Zeno wrote in the 52nd comment:
Votes: 0
If Smaug has this:
nRead = recv( d->descriptor, d->inbuf + iStart, sizeof( d->inbuf ) - 10 - iStart, 0 );
#ifdef WIN32
iErr = WSAGetLastError( );
#else
iErr = errno;
#endif
if( nRead > 0 )
{
iStart += nRead;

and I changed that last line to:
iStart += translate_telopts(d,d->inbuf + iStart,nRead,(d->inbuf + iStart));

Is that right? Or do I not need to add iStart to d->inbuf there?

I mean it's working, but I'm not sure if it would be the wrong way to do that.

You can test it at zeno.biyg.org 3251, I already tested it with your client and it seemed fine.
16 Mar, 2009, David Haley wrote in the 53rd comment:
Votes: 0
It will break in the event of packet fragmentation. While this is not likely to be a problem for receiving MSSP requests, it is still a broken telnet handler. I would recommend using Elanthis's libtelnet if you want to do stuff with subnegotiation.
16 Mar, 2009, Scandum wrote in the 54th comment:
Votes: 0
Zeno said:
iStart += translate_telopts(d,d->inbuf + iStart,nRead,(d->inbuf + iStart));

That looks alright, though the extra parenthesis shouldn't be necessary.

Zeno said:
You can test it at zeno.biyg.org 3251, I already tested it with your client and it seemed fine.

Looks good, what'll be the next release number? (So I can update the mssp page).

David Haley said:
It will break in the event of packet fragmentation. While this is not likely to be a problem for receiving MSSP requests, it is still a broken telnet handler. I would recommend using Elanthis's libtelnet if you want to do stuff with subnegotiation.

As discussed before, packet fragmentation is a once in a lifetime occurrence with the current implementation of very short telnet messages. I ran the prototype of mth for years without any problems or glitches.

In the event a mud wants to implement zmp or another chunky protocol it's fairly easy to add protection against packet fragmentation at a non notable processing speed cost, without dealing with the bulkiness, readability, and maintainability issues of a full fledged state machine. Also keep in mind that many muds avoid big buffers, the snippet would become pretty useless for zmp if a mud with a 512 Byte input buffer sets the packet patch buffer to 512 Bytes as well.
16 Mar, 2009, Zeno wrote in the 55th comment:
Votes: 0
Quote
Looks good, what'll be the next release number? (So I can update the mssp page).

It'll be up to the FUSS team if they include my patch in FUSS or not.

At the very least, any MUD I run will have MSSP. I'll let you know when those have MSSP.
16 Mar, 2009, David Haley wrote in the 56th comment:
Votes: 0
Scandum said:
In the event a mud wants to implement zmp or another chunky protocol it's fairly easy to add protection against packet fragmentation at a non notable processing speed cost, without dealing with the bulkiness, readability, and maintainability issues of a full fledged state machine.

Sometimes the things you say just boggle my mind. :stare:
17 Mar, 2009, Kline wrote in the 57th comment:
Votes: 0
David Haley said:
It will break in the event of packet fragmentation. While this is not likely to be a problem for receiving MSSP requests, it is still a broken telnet handler. I would recommend using Elanthis's libtelnet if you want to do stuff with subnegotiation.


I'd like to move to Elanthis' libtelnet, just because it seems a bit easier to plug-and-play values into, but it's not quite in a (fully) working/finished state, from what I understand?
17 Mar, 2009, Scandum wrote in the 58th comment:
Votes: 0
I could add plug and play "do will don't won't" support to MTH, but that'd likely require a 256 byte data structure per descriptor to do it properly.
17 Mar, 2009, Cratylus wrote in the 59th comment:
Votes: 0
Telnet to: dead-souls.net 8000

Instead of a username, type: MSSP-REQUEST

Simple. Useful.

-Crat
17 Mar, 2009, elanthis wrote in the 60th comment:
Votes: 0
Scandum said:
I could add plug and play "do will don't won't" support to MTH, but that'd likely require a 256 byte data structure per descriptor to do it properly.


No, it doesn't.
40.0/292