20 Feb, 2009, Tyche wrote in the 42nd comment:
Oh .. consider the potential of the IAC SB NEW-ENVIRON INFO
A server could decide to send out regularly updated USERVAR during the course of a client's connection, like every 'tick'.
If a mud client understood NEW-ENVIRON made these USERVAR available to it's script language environment, then that opens up a ton of more possibilities for a mud to collaborate with client scripts.
No I really don't consider that Telnet protocols contain NUL and IAC escapes a problem at all. Obviously you do need a correct working implementation for anyone to do it at all.
That said, it might make more sense to create a new option code (aka MSSP) that doesn't use the NUL, that would allow you to create a list of standard VAR, and the freedom to load USERVAR with particular and peculiar stuff, and even allow the option work bidirectional (unlike NEW-ENVIRON). So clients can send the mud server information.
But I'd study all the implications of NEW-ENVIRON option, the way it's built with it's SEND IS INFO options, and the way partial lists or specific VAR USERVAR can be requested. It seems well conceived.
A server could decide to send out regularly updated USERVAR during the course of a client's connection, like every 'tick'.
If a mud client understood NEW-ENVIRON made these USERVAR available to it's script language environment, then that opens up a ton of more possibilities for a mud to collaborate with client scripts.
No I really don't consider that Telnet protocols contain NUL and IAC escapes a problem at all. Obviously you do need a correct working implementation for anyone to do it at all.
That said, it might make more sense to create a new option code (aka MSSP) that doesn't use the NUL, that would allow you to create a list of standard VAR, and the freedom to load USERVAR with particular and peculiar stuff, and even allow the option work bidirectional (unlike NEW-ENVIRON). So clients can send the mud server information.
But I'd study all the implications of NEW-ENVIRON option, the way it's built with it's SEND IS INFO options, and the way partial lists or specific VAR USERVAR can be requested. It seems well conceived.
20 Feb, 2009, elanthis wrote in the 43rd comment:
I have to agree that, given the intended use-case, TELNET option negotiation is the wrong thing to use. Just make the spec say that if the very first bytes send by the client are the string "MSSP-REQUEST\r\n" then immediately spit out "\r\nMSSP-RESPONSE\r\n", followed by a line like "<key>: <value>\r\n" for each datum (where <key> is required to be one more letters, numbers, or underscores; and <value> can be any series of bytes not including 0x00 or 0xFF, and should use C-style backslash escapes for newlines and such), followed another "\r\n" (a blank line). Clients, upon receiving the blank line, should immediately disconnect if they are not interested in communicating with the MUD itself further. That then is VERY VERY easy to implement both within a regular MUD client or a dedicated status aggregator.
A dedicated client has it really easy. It connects and spits out "MSSP-REQUEST\r\n". Then it just ignores data until it sees "MSSP-RESPONSE\r\n" and starts using a very simple state-machine almost identical to what you'd use for HTTP headers. I wouldn't be surprised if it could be implemented in like 4-5 lines of Ruby or Perl.
A dedicated client has it really easy. It connects and spits out "MSSP-REQUEST\r\n". Then it just ignores data until it sees "MSSP-RESPONSE\r\n" and starts using a very simple state-machine almost identical to what you'd use for HTTP headers. I wouldn't be surprised if it could be implemented in like 4-5 lines of Ruby or Perl.
20 Feb, 2009, Scandum wrote in the 44th comment:
Tyche said:
No I really don't consider that Telnet protocols contain NUL and IAC escapes a problem at all. Obviously you do need a correct working implementation for anyone to do it at all.
It's not really a problem, but it results in adding tedious exceptions, code bloat, maintainability issues, etc. Even telnet doesn't get IAC IAC behavior in NAWS right, it works, but the debug output is incorrect. So one line of code easily becomes 10-50 lines just to get it right, which in turn makes a snippet that much less attractive.
Tyche said:
That said, it might make more sense to create a new option code (aka MSSP) that doesn't use the NUL, that would allow you to create a list of standard VAR, and the freedom to load USERVAR with particular and peculiar stuff, and even allow the option work bidirectional (unlike NEW-ENVIRON). So clients can send the mud server information.
I thought about that, but the TELNET protocol is prone to looping in that case. I think it'd be preferable to add MCSP.
Tyche said:
But I'd study all the implications of NEW-ENVIRON option, the way it's built with it's SEND IS INFO options, and the way partial lists or specific VAR USERVAR can be requested. It seems well conceived.
I'll give partial listing some thought, but I'm not sure of its utility since clients can discard uservars they don't care about.
elanthis said:
A dedicated client has it really easy. It connects and spits out "MSSP-REQUEST\r\n". Then it just ignores data until it sees "MSSP-RESPONSE\r\n" and starts using a very simple state-machine almost identical to what you'd use for HTTP headers. I wouldn't be surprised if it could be implemented in like 4-5 lines of Ruby or Perl.
I don't see the big difference between spitting out IAC WILL MSSP IAC SB MSSP ETC and waiting for IAC SB MSSP ETC. With the added benefit that a mud server with a decent telnet implementation will already answer back and inform the client it doesn't support MSSP.
20 Feb, 2009, David Haley wrote in the 45th comment:
The problem here is that you think that everybody will find subneg to be easy, because things like MCCP are commonplace. The only reason those things are commonplace is that somebody snippetized them or added them to stock codebases. The average MUD coder is probably not very good at all with subneg, or even networking in general.
I still haven't seen a compelling reason to make this use subneg. The idea of autopopulating a client's connection manager seems rather weak, and besides, the exact same thing could be accomplished using the plain ol' text method.
I still haven't seen a compelling reason to make this use subneg. The idea of autopopulating a client's connection manager seems rather weak, and besides, the exact same thing could be accomplished using the plain ol' text method.
20 Feb, 2009, Scandum wrote in the 46th comment:
I guess an added benefit in that case is that muds with lousy programmers are automatically excluded.
20 Feb, 2009, Kayle wrote in the 47th comment:
So then, because I don't have the entire telnet protocol memorized, or care to memorize it, that makes me a lousy programmer? Good to know.
20 Feb, 2009, David Haley wrote in the 48th comment:
Scandum said:
I guess an added benefit in that case is that muds with lousy programmers are automatically excluded.
Good luck promoting protocol adoption with that attitude! Whee.
20 Feb, 2009, KaVir wrote in the 49th comment:
Scandum said:
I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.
Cratylus said:
I like the idea in general. i do not like the straitjacketed categories.
Some of those things just don't apply for a lot of muds.
Some of those things just don't apply for a lot of muds.
I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.
So what would a roomless mud be listed as? 0 rooms (because it doesn't use rooms)? 1 room (because the entire world could technically be considered a 'room')? Something else?
Scandum said:
I guess an added benefit in that case is that muds with lousy programmers are automatically excluded.
No, that isn't a benefit if you're creating a mud directory.
20 Feb, 2009, Scandum wrote in the 50th comment:
If implementing a telopt parser is above your skill or dedication level that's not a problem, just say so instead of demanding a hack job.
Like I mentioned earlier, I can provide a public domain telopt parsing snippet, and if you have any trouble implementing it I'd be happy to answer any questions.
Like I mentioned earlier, I can provide a public domain telopt parsing snippet, and if you have any trouble implementing it I'd be happy to answer any questions.
20 Feb, 2009, Scandum wrote in the 51st comment:
KaVir said:
So what would a roomless mud be listed as? 0 rooms (because it doesn't use rooms)? 1 room (because the entire world could technically be considered a 'room')? Something else?
Scandum said:
I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.
Cratylus said:
I like the idea in general. i do not like the straitjacketed categories.
Some of those things just don't apply for a lot of muds.
Some of those things just don't apply for a lot of muds.
I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.
So what would a roomless mud be listed as? 0 rooms (because it doesn't use rooms)? 1 room (because the entire world could technically be considered a 'room')? Something else?
0 would bring the point across that it's a roomless mud. I assume there would be areas of sorts, so you could for example still list 134 areas, and 430 unique mobiles to give an indication of content.
Scandum said:
I guess an added benefit in that case is that muds with lousy programmers are automatically excluded.
No, that isn't a benefit if you're creating a mud directory.
Probably not, it depends on your goals, at least you'd be able to provide accurate up to date information.
20 Feb, 2009, David Haley wrote in the 52nd comment:
Scandum said:
If implementing a telopt parser is above your skill or dedication level that's not a problem, just say so instead of demanding a hack job.
You're talking to the wrong people, Scandum…
Besides, it is hardly a hack job to move communication to the, err, communication level instead of the sub-communication. So far, the only motivation at all that you have provided for keeping things on subneg is so that clients can autopopulate connection info…
Scandum said:
Like I mentioned earlier, I can provide a public domain telopt parsing snippet
That average MUD devs out there will be able to use?
Scandum said:
and if you have any trouble implementing it I'd be happy to answer any questions.
Are you offering support for "the world"?
20 Feb, 2009, Cratylus wrote in the 53rd comment:
Scandum said:
If implementing a telopt parser is above your skill or dedication level that's not a problem, just say so instead of demanding a hack job.
Like I mentioned earlier, I can provide a public domain telopt parsing snippet, and if you have any trouble implementing it I'd be happy to answer any questions.
Like I mentioned earlier, I can provide a public domain telopt parsing snippet, and if you have any trouble implementing it I'd be happy to answer any questions.
I happen to have messed with similar negotiation
stuff pretty recently, in order to implement up-arrow
command recall and such on the lib I maintain. I am
really not worried about my capacity for accommodating
this scheme. I am honestly, genuinely in love with the
idea of a standardized mud surveying protocol that can
be widely and easily adopted.
I just also think that this insistence on making it use
neg/opt stuff is an error that makes your proposal "not it".
:(
-Crat
http://lpmuds.net
20 Feb, 2009, David Haley wrote in the 54th comment:
I have an easy solution. I propose a standard, let's call it, say, Mud Server Status Update Protocol, that does the above except it uses a plaintext format similar to what Elanthis suggested.
Whee, problem solved, if people are serious about making something like this happen.
Whee, problem solved, if people are serious about making something like this happen.
20 Feb, 2009, Cratylus wrote in the 55th comment:
DavidHaley said:
I have an easy solution. I propose a standard, let's call it, say, Mud Server Status Update Protocol, that does the above except it uses a plaintext format similar to what Elanthis suggested.
Whee, problem solved, if people are serious about making something like this happen.
Whee, problem solved, if people are serious about making something like this happen.
That's what I'm talkin bout bro. Let's get 'er done.
That settled, the two protocols share the problem of categories. I'd like to
know Kavir's opinion on how rommlessness should be reported.
-Crat
http://lpmuds.net
20 Feb, 2009, Scandum wrote in the 56th comment:
Why not just dumb it down a notch?
MUDs can search for the char iac_sb_mssp = { IAC, SB, MSSP, MSSP_GIVE, MSSP_MUDVAR, IAC, SE }; string.
More correctly the crawler can send: IAC DO MSSP IAC SB MSSP MSSP_GIVE MSSP_MUDVAR IAC SE and the server could add a check to filter out IAC DO MSSP.
By omitting the 0 byte it can be implemented as a basic text protocol.
Protocol update:
client - IAC DO MSSP IAC SB MSSP MSSP_GIVE MSSP_MUDVAR IAC SE
server - IAC WILL MSSP IAC SB MSSP MSSP_TAKE MSSP_MUDVAR "ROOMS" MSSP_VALUE "15000" MSSP_MUDVAR "PLAYERS" MSSP_VALUE "52" MSSP_MUDVAR "OBJECTS" MSSP_VALUE "12345" IAC SE
MUDs can search for the char iac_sb_mssp = { IAC, SB, MSSP, MSSP_GIVE, MSSP_MUDVAR, IAC, SE }; string.
More correctly the crawler can send: IAC DO MSSP IAC SB MSSP MSSP_GIVE MSSP_MUDVAR IAC SE and the server could add a check to filter out IAC DO MSSP.
By omitting the 0 byte it can be implemented as a basic text protocol.
Protocol update:
"ROOMS" Current number of unique rooms, use "0" for roomless muds.
20 Feb, 2009, KaVir wrote in the 57th comment:
Cratylus said:
That settled, the two protocols share the problem of categories. I'd like to know Kavir's opinion on how rommlessness should be reported.
Listing it as 0 rooms is probably okay.
However I noticed that Scandum refers to the rooms as "unique rooms" in later posts. If you have 2 identical rooms, does that count as 1 unique room, or 0 unique rooms? Also, how much does one room need to differ from another in order to be classified as "unique"?
20 Feb, 2009, David Haley wrote in the 58th comment:
KaVir said:
However I noticed that Scandum refers to the rooms as "unique rooms" in later posts. If you have 2 identical rooms, does that count as 1 unique room, or 0 unique rooms? Also, how much does one room need to differ from another in order to be classified as "unique"?
I had the same question about characters with slight variations from prototypes, and the answer was "life is unfair".
I think that in practice, the definition should be left intentionally (but explicitly) vague so that the MUD gives whatever answer its admin would give when filling out a form. It's not really possible IMO to have some kind of Grand Unified Ontology for MUDs so that you can give answers according to that ontology.
21 Feb, 2009, Scandum wrote in the 59th comment:
KaVir said:
However I noticed that Scandum refers to the rooms as "unique rooms" in later posts. If you have 2 identical rooms, does that count as 1 unique room, or 0 unique rooms? Also, how much does one room need to differ from another in order to be classified as "unique"?
If your mud implements template rooms, I'd suggest you'd use the amount of templates, and not the amount of instances of that template. This isn't really an issue on traditional Merc derivatives because every room is unique.
I'd also say that a unique room can contain a unique list of objects. So 2 identical rooms would be 2 unique rooms if each can hold a unique list of objects.
21 Feb, 2009, David Haley wrote in the 60th comment:
Scandum said:
If your mud implements template rooms, I'd suggest you'd use the amount of templates, and not the amount of instances of that template. (…) So 2 identical rooms would be 2 unique rooms if each can hold a unique list of objects
So it's not templates but instances after all?
BTW, if the protocol is supposed to talk to lots of different MUDs, don't you sort of have to care about problems that Dikus don't have but others might?
Random Picks
I fundamentally disagree with you here. I personally wouldn't implement a protocol that is non transparent on my own mud server. I think omitting the usage of 0 bytes is a good concession though, it's a big headache, especially for newbie programmers and idiots. Also, once you have a decent telopt handler it's easy to add non ambiguous protocols.
Why does your preference about the protocol mean that I'm wrong about adoption?
Easier to do means more muds do it which means more data which means more usefulness since it's about surveying.
It sounds to me like you just don't care about getting as many muds to participate
as possible. If you're not going to be as inclusive as possible, why bother?
-Crat
http://lpmuds.net