06 Mar, 2009, elanthis wrote in the 21st comment:
Votes: 0
David Haley said:
If you actually use write_to_descriptor, yes, it is sent right away. But most people don't do that, and use the methods that instead buffer input until the next network update (e.g. send_to_char). I'm not really sure why the direct method is being discussed since it's not used in the vast majority of cases.


I made an example post of printf_to_descriptor() many pages back, not realizing that it was actually very close to a standard Diku/ROM/whatever function call. It was meant as an example of a function that allowed you to printf() into a character's output buffer, NOT write directly to the socket descriptor.
06 Mar, 2009, Kline wrote in the 22nd comment:
Votes: 0
void mssp_reply( DESCRIPTOR_DATA* d, const char* key, const char* value ) && void mssp_reply( DESCRIPTOR_DATA* d, const char* key, int value )

Were what I was referring to, elanthis. I think it was you who suggested functions similar to that? Just something better than a monolithic sprintf.
06 Mar, 2009, Kline wrote in the 23rd comment:
Votes: 0
Scandum said:


I'd like this just for looks, ie, all countries represented by a 2 letter abbr. Just standardization.
06 Mar, 2009, elanthis wrote in the 24th comment:
Votes: 0
Kline said:
Were what I was referring to, elanthis. I think it was you who suggested functions similar to that? Just something better than a monolithic sprintf.


Indeed, ever so much cleaner, the resulting code will be much easier to read and modify. Way less manly, though; using sprintf will help put hair on your ass.
06 Mar, 2009, Scandum wrote in the 25th comment:
Votes: 0
Kline said:
Scandum said:

I'd like this just for looks, ie, all countries represented by a 2 letter abbr. Just standardization.

Those are not human readable though, forcing crawlers to translate them. I think it'll be better to use the short country names provided by the standard and link the Wikipedia article.

http://en.wikipedia.org/wiki/ISO_3166-1

Edit: Went ahead and updated the article stating to use the official country name as defined by ISO 3166. Linking to the Wikipedia article so people don't put the countries in all caps, which looks kind of ugly.
10 Mar, 2009, Scandum wrote in the 26th comment:
Votes: 0
Recent updates to the protocol:

"FAMILY"              "AberMUD", "CoffeeMUD", "DikuMUD", "LPMud", "MajorMUD", "MOO", "Mordor", "Rapture", "TinyMUD", "Custom". 
"LOCATION" Full English name of the country where the server is located, using ISO 3166.


The "PREROGATIVE" variable has been removed, and should be replaced with "FAMILY", which offers a value list to pick from, and should give the most distant generic codebase the mud is derived from, unless it's a custom codebase.
12 Mar, 2009, Scandum wrote in the 27th comment:
Votes: 0
Added the option for muds to report their SSL port.

"SSL" SSL port ? Use "0" if not supported.
12 Mar, 2009, elanthis wrote in the 28th comment:
Votes: 0
Which MUDs actually use SSL? (Genuine curiosity)
12 Mar, 2009, Scandum wrote in the 29th comment:
Votes: 0
Only one I know the addy of is: avalon.mud.de:7778 The normal port is 7777 I think.

It's not overly difficult to set up a proxy for it with stunnel, though I'm clueless what the exact added benefit is. There are some bizarre anti free speech laws in Germany though, maybe that's why.
13 Mar, 2009, Scandum wrote in the 30th comment:
Votes: 0
As per Kiasyn's request I updated the protocol as following:

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. It's also possible to attach several values to a single variable by using MSSP_VAL more
than once, with the default value reported last. This would look as following:

IAC SB MSSP MSSP_VAR "PORT" MSSP_VAL "80" MSSP_VAL "23" MSSP_VAL "3000" MSSP_VAR "CREATED" MSSP_VAL "1996" IAC SE
13 Mar, 2009, quixadhal wrote in the 31st comment:
Votes: 0
Not sure if this is related or not, but some LP muds have ssh support. I can see SSH being useful, as it would allow you to use key exchange instead of username/password to connect. That would be especially handy for muds that use accounts and have multiple characters under each one.
13 Mar, 2009, Scandum wrote in the 32nd comment:
Votes: 0
I assume they have a different ssh port?
13 Mar, 2009, David Haley wrote in the 33rd comment:
Votes: 0
I think that it is a Very Bad Idea to leave it up to the crawler's discretion how to handle multiple values. For several things multiple values are truly important information, so it really isn't an option to just toss things that aren't convenient for a crawler to parse.
13 Mar, 2009, Scandum wrote in the 34th comment:
Votes: 0
All multi value variables consists of duplicates, with the exception of intermud, and intermud servers can be stored as a bitfield client side anyways. It should also be fairly easy to use a LIFO list.
13 Mar, 2009, elanthis wrote in the 35th comment:
Votes: 0
quixadhal said:
Not sure if this is related or not, but some LP muds have ssh support. I can see SSH being useful, as it would allow you to use key exchange instead of username/password to connect. That would be especially handy for muds that use accounts and have multiple characters under each one.


TELNET actually has full support for authentication and encryption.

If you just care about protecting passwords, you could use TELNET's AUTHENTICATION negotiation with SRP, which is a pretty neat protocol for safely authenticating with passwords without ever sending the password (or a predictable hash) over the wire. Or you could just use STARTTLS to enable encryption during login.

Actually, it's a shame TELNET doesn't have SASL support. Easily remedied!
14 Mar, 2009, Scandum wrote in the 36th comment:
Votes: 0
I wrote a mud crawler for tintin++ today and its output is available here:

http://tintin.sourceforge.net/mssp/mudli...

It's pretty basic so far, if you add MSSP to your mud give me a yell and I'll add you to the crawl list.
14 Mar, 2009, Kline wrote in the 37th comment:
Votes: 0
Was wondering what all the connections were :)
14 Mar, 2009, Les wrote in the 38th comment:
Votes: 0
I just added support for MSSP into gnome-mud, it will go live on the next release. Right now it's sitting in our repo trunk. Gnome-mud doesn't do much with the data yet other than expose it as a hashtable. Figure plugins might find it useful if nothing else.

To see the data you will need to compile gnome-mud with –enable-debug-logger=TRUE
14 Mar, 2009, Scandum wrote in the 39th comment:
Votes: 0
That's the client located at http://amcl.sourceforge.net ? (Asking since the last reported update was in 2005).
14 Mar, 2009, Les wrote in the 40th comment:
Votes: 0
Scandum said:
That's the client located at http://amcl.sourceforge.net ? (Asking since the last reported update was in 2005).


http://live.gnome.org/GnomeMud is the main page for it. If I could nuke that ancient sourceforge site I would :(
20.0/292