19 Feb, 2009, David Haley wrote in the 22nd comment:
Scandum said:
Isn't Unix time by default in UTC?
It's supposed to, but people can "cheat" on their systems by changing the hardware time to be their localtime, and then not futzing with time zones. I just think it's worth mentioning it, just to make sure everybody is on the same page.
Scandum said:
Unique as in prototypes, rather than objects.
What if a MUD doesn't treat prototypes the same way? For example, you could very well have a "prototype" that gets instantiated with variation every time. For instance, the name could be randomly generated, the stats tweaked, maybe even have an automatically generated description. (Think of a town-person generator, for example.) Although each mob nominally has the same prototype, it is not the same kind of relationship that most Diku mobs have to their prototype. Such a MUD would unfairly appear to have many fewer unique mobs than the Diku MUD.
Scandum said:
And a mud written in a scripting language would need a way to separately count area based scripts from other scripts, or skip the option if they find it irrelevant. Most Dikus don't have a noticeable amount of scripts and probably won't bother counting the amount of lines.
But how do you distinguish this? At what point does a script stop being a builder's script, and start being a "core" script? When it's shared by several areas? (What if you don't even use the term 'area' the same way?) What if you have a catalog of scripts to implement common behavior, and these scripts don't live in any particular area: do those count as script lines? (What if Joe copy/pastes all of his scripts instead of having a shared script mechanism, does he get more lines than me?)
The problem is that generally people think "more is better" with this kind of thing (mob/obj/room/script-line count, etc.), so if the protocol favors one method of counting, it is basically putting everybody else at a disadvantage. What exactly is the intention here? You might argue that the protocol should get you the same value that the human being would put into the web form, so it doesn't matter how you define it. But I feel that a protocol, with its strict definitions, would add false authenticity or objectivity to those numbers, where in reality the meaning of the numbers varies greatly across individual MUDs, and especially codebases.
19 Feb, 2009, Scandum wrote in the 23rd comment:
DavidHaley said:
It's supposed to, but people can "cheat" on their systems by changing the hardware time to be their localtime, and then not futzing with time zones. I just think it's worth mentioning it, just to make sure everybody is on the same page.
You can cheat as well by sending 0 and making it look like your mud has been continuously up since 1970.
DavidHaley said:
What if a MUD doesn't treat prototypes the same way?
What can I say, life ain't fair.
DavidHaley said:
But I feel that a protocol, with its strict definitions, would add false authenticity or objectivity to those numbers, where in reality the meaning of the numbers varies greatly across individual MUDs, and especially codebases.
Which is why most people search by codebase, or amount of players.
19 Feb, 2009, David Haley wrote in the 24th comment:
Scandum said:
You can cheat as well by sending 0 and making it look like your mud has been continuously up since 1970.
Perhaps I shouldn't have used the word "cheat", even in quotation marks, because I wasn't trying to say that somebody would be deliberately sending a bad value. I was trying to say that somebody might configure your machine to think that its local time is UTC.
I'm not sure why it's so objectionable to just make the protocol say that UTC is expected.
Scandum said:
What can I say, life ain't fair.
If a protocol is claiming to create a unified data retrieval interface, and yet that data is not comparable across codebases, you have in some sense failed before having even begun.
Obviously it is not practical to make the protocol responsible for working out how some MUD works or thinks of mobs, areas, or whatever. But you have baked very many assumptions into your protocol field definitions that do not always hold. Either the protocol needs to have very clear definitions of how to compute values, or you accept that the values are incomparable. But as I said earlier, "you might argue that the protocol should get you the same value that the human being would put into the web form, so it doesn't matter how you define it." I just think it should be clear, if this is indeed the goal, from the outset that the definitions are fuzzy.
20 Feb, 2009, Scandum wrote in the 25th comment:
It'll never be perfect and I don't expect it to be, but if you see room for improvement feel free to comment. This'd be just a little toy for interested programmers to add to their muds, if someone ever gets around to writing an actual server side snippet for it that anyone bothers to look at.
Am I missing anything?
Am I missing anything?
/*
Various USERVAR values:
*/
"UPTIME" Unix time value of the startup time of the MUD.
"HOSTNAME" Current or new hostname.
"IP" Current or new IP address.
"PORT" Current or new port number.
"PLAYERS" Current number of players online.
"BANDWIDTH" Current average bandwidth per month in Megabytes.
"AREAS" Current number of unique areas.
"ROOMS" Current number of unique rooms.
"MOBILES" Current number of unique mobs.
"OBJECTS" Current number of unique objs.
"SCRIPTLINES" Current number of unique world related script lines.
"HELPFILES" Current number of help files.
"CODEBASE" Name of the codebase, eg "Merc"
"PREROGATIVE" Name of the prerogative codebase, eg "DikuMUD" or "Custom"
"LANGUAGE" Name of the language used, eg "German" or "English"
"LOCATION" Name of the location of the server, eg "France" or "USA"
"LAUNCHED" Year the MUD was launched.
"GENRE" "Science Fiction", "Fantasy", "Historical", "Horror", or "Western"
"GAMEPLAY" "Adventure", "Educational", "Hack and Slash", "Player versus Player", "Roleplaying", "Social", "Strategy"
/*
All values are assumed to be "0" if omitted
*/
"ANSI" Supports ANSI colors ? if yes use "1" : if no use "0"
"MCCP" Supports MCCP ?
"MCP" Supports MCP ?
"MSP" Supports MSP ?
"MXP" Supports MXP ?
"PUEBLO" Supports Pueblo ?
"VT100" Supports VT100 interface ?
"XTERM 256 COLORS" Supports XTERM 256 COLORS ?
"FREE TO PLAY" Free to play ? if yes use "1" : if no use "0"
"PAY FOR PERKS" Pay for perks ?
"ADULT" Adult game ?
"ALPHA" "1" or "0"
"BETA" "1" or "0"
"HIRING" "1" or "0"
"RACELESSS" "1" or "0"
"CLASSLESS" "1" or "0"
"LEVELESS" "1" or "0"
"COMBATLESS" "1" or "0"
20 Feb, 2009, Tyche wrote in the 26th comment:
Scandum said:
I'm clueless what LASG stands for?
Lesbian Asian School Girls!
Scandum said:
It would, even the IP address could be set automatically.
I was thinking the protocol might get more traction if some of the listing site's spiders adopted it. While you could send IP and port, it's sort of redundant since the client had to know that to connect.
Sure any mud could spoof their data. Hell they already do on their listings anyway. ;-)
20 Feb, 2009, Tyche wrote in the 27th comment:
Cratylus said:
If the idea here is a spec that is to be widely useful and adopted, then I think
it is necessary to entertain the notion that your favorite ultra efficient method
may not actually achieve the goal of being widely used, and should be reconsidered.
Scandum said:
Oh joy, another !!MSP cludge?
If the idea here is a spec that is to be widely useful and adopted, then I think
it is necessary to entertain the notion that your favorite ultra efficient method
may not actually achieve the goal of being widely used, and should be reconsidered.
I guess no one adopted the MSP2 spec.
20 Feb, 2009, David Haley wrote in the 28th comment:
Quote
"GENRE" "Science Fiction", "Fantasy", "Historical", "Horror", or "Western"
"GAMEPLAY" "Adventure", "Educational", "Hack and Slash", "Player versus Player", "Roleplaying", "Social", "Strategy"
Can one select multiple values here, esp. for gameplay? How about being able to put in your own strings, in case your genre isn't covered?
EDIT: it might be easier to make a new post so that it shows up in the list when you add something several hours later; I didn't notice you'd added all that stuff until Tyche posted, and I saw code showing up that I hadn't noticed before.
20 Feb, 2009, Cratylus wrote in the 29th comment:
Tyche said:
I guess no one adopted the MSP2 spec.
I was, of course, only addressing Scandum's apparent disdain for
the high-level approach…I don't know much about MSP so I looked it
up just now.
It gives me a better understanding of the original approach in this
thread. MSP also uses telnet options…it seems that telnet option
stuff is common for extended mud client stuff…and indeed it seems
a very good way to establish those compatibilities with minimal
user savvy or even awareness.
Options appear a natural approach to the unobtrusive negotiation
of extra stuff when it's paired with regular user input. If that is the
intended use of MSSP…giving your mud client this data…then it clicks
for me.
However, this intended use does not itself interest nor enthuse me
as what I had thought the point was. I thought this was to make it
easier for mud listing sites/applications to compile and provide data.
That is a useful thing that is practical and not unreasonable to
believe is a reachable goal worth the effort. Doing this for some
small subset of folks that happen to use a client that implements it…
that is…not so compelling to me.
What exactly did you have in mind, Scandum?
-Crat
http://lpmuds.net
20 Feb, 2009, David Haley wrote in the 30th comment:
I think his idea is that only the listing sites would use the subneg in the first place; normal players' clients wouldn't need to know about the protocol at all.
20 Feb, 2009, Cratylus wrote in the 31st comment:
DavidHaley said:
I think his idea is that only the listing sites would use the subneg in the first place; normal players' clients wouldn't need to know about the protocol at all.
That also had been my understanding, which is why I think a simple process of:
1) querent script connects to the mud port, issues a special query string.
2) mud recognizes the input as "not a connecting player" and parses the query.
3) mud replies with a response in the proper format.
4) querent script disconnects.
Would do just fine, without the added complexity of telnet options.
-Crat
http://lpmuds.net
20 Feb, 2009, David Haley wrote in the 32nd comment:
Well, as I said in #8, I'm not sure I see the point either. Why are subnegs being used here, if there is no first-class "negotiation" (i.e. communication) in the first place?
20 Feb, 2009, quixadhal wrote in the 33rd comment:
If the purpose is to allow mud listing sites to obtain statistical information about the mud, I'd suggest just using an alternate port, or a fixed username which just emits the available data in a simple key/value pair format and disconnects. That way, the mud list can parse for what it wants, and the admin is free to add whatever extra data they wish.
20 Feb, 2009, Tyche wrote in the 34th comment:
Cratylus said:
I was, of course, only addressing Scandum's apparent disdain for
the high-level approach…I don't know much about MSP so I looked it
up just now.
Tyche said:
I guess no one adopted the MSP2 spec.
I was, of course, only addressing Scandum's apparent disdain for
the high-level approach…I don't know much about MSP so I looked it
up just now.
I think Scandum was referring to the problem with MSP. It doesn't do Telnet subnegotiation. After negotiating the option it doesn't send any subnegotiation, so your stream has to send lines beginning with !!SOUND or !!MUSIC.
Here's the MSP2 spec:
Quote
Mesh Project Matthew Chaplain
Request For Comments Vision Codebase
March 2004
Mud Sound Protocol 2
Status of this Memo
This RFC descripbes a proposed Telnet option to allow a server to
tell a client to play music or sound files. Distribution of this
memo is unlimited.
1. Command Name and Option Code
Name = MSP2 (Mud Sound Protocol 2)
Code = 92
Name = MUSIC
Code = 0
Name = SOUND
Code = 1
2. Conventions used in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
In examples, "C:" represents lines sent by a protocol client and
"S:" represents lines returned by a protocol server. Indentation
and white space in examples is provided only to illustrate element
relationships and is not a feature of this specification.
In command descriptions, words enclosed in angle brackets are used
as variable name placeholders rather than literals. Braces are used
to group elements. In particular, braces with an ellipsis (…) show
a block that can be repeated. Finally, square brackets denote
optional parameters.
A string is a 0-terminated (i.e: a series of ASCII characters with a
trailing character of value 0) string. In protocol descriptions,
this terminator will be marked up as "\0".
3. Motivation for this option.
The genre of online text base adventures known collectively as
"Muds" has become somewhat stagnant, when it comes to displaying
information. Most muds are built from codebases which implement
only the basic fundamentals of the Telnet protocol. Notably, how to
say "No, I don't support that feature."
For this reason, clients have also become stagnant. Although
features such as mapping, aliases and triggered actions have become
popular, muds have had to remain as streaming text, left-to-right,
top-to-bottom, since many of the more "advanced" clients do not
support the full set of ANSI escape codes available to them. Thus,
it is almost impossible to tell what the output of a mud trying to
use these features will look like.
One or two muds have tried to break the mould by implementing their
output via an API such as "Curses" that uses these escape codes to
format the output of the muds. While this is a step in the right
direction, there are a few inherent problems.
During this period of stagnation, some other options have been
created to attempt to enhance the user experience. One of these is
the Mud Sound Protocol, a specification for which can be found (at
the time of writing) at http://www.zuggsoft.com/zmud/msp.htm. This
protocol assumes that the server outputs in line mode, yet with the
aforementioned ANSI escape code APIs, linemode does not exist.
Hence, the two do not interoperate.
This option intends to rectify that problem by reimplementing it
inside the telnet protocol, which can be separated easily from the
escape codes.
4. Command Meanings
4.1 Enabling Commands
S: IAC WILL MSP2
Sent by the Telnet Server to suggest that MSP2 be used, or
to agree to its use.
S: IAC WONT MSP2
Sent by the Telnet Server to refuse to use MSP2.
C: IAC DO MSP2
Sent by the Telnet Client to suggest that MSP2 be used, or
to agree to its use.
C: IAC DONT MSP2
Sent by the Telnet Client to refuse to use MSP2.
4.2 Subnegotiations
S: IAC SB MSP2 MUSIC <filename> [{<param1> <value1> …}] IAC SE
Sent by the Telnet Server to ask the client to play a
particular music file.
S: IAC SB MSP2 SOUND <filename> [{<param1> <value1> …}] IAC SE
Sent by the Telnet Server to ask the client to play a
particular sound file.
Filename is a string (see conventions) containing an optional path
to the name of a sound or music file. It may contain wildcards in
the form of at most one asterisk (*) and/or any number of question
marks (?). An asterisk can be used to match any number of
characters, whereas a question mark can match one and only one
character. If several matches are available after the wildcards
have been resolved, one is chosen at random.
4.3 Parameters
Name : Volume
Code : V
Values : 0-100
Default : 100
Used In : SOUND, MUSIC
Description : Sets the volume for this specific sound or music
invocation. 0 is minimum volume - muted. 100 is
maximum volume.
Example :
S: IAC SB MSP2 SOUND clank.wav\0 V 50 IAC SE
(plays clank.wav as a sound at half volume)
Name : Repeats
Code : L
Values : 0-65535
Default : 1
Used In : SOUND, MUSIC
Description : Specifies the number of times this sound or music
should be played. 0 is a special case where the sound
or music is played indefinitely, until instructed
otherwise. In the protocol, the value is specified
most significant byte first.
Example :
S: IAC SB MSP2 MUSIC bg.mid\0 L 0 44 IAC SE
(plays bg.mid 44 times)
S: IAC SB MSP2 MUSIC bg.mid\0 L 1 44 IAC SE
(plays bg.mid 300 times)
Name : Priority
Code : P
Values : 0-100
Default : 50
Used In : SOUND
Description : Specifies the priority of a soundbyte. If a new
request with an equal or lower priority is received,
the new request is ignored. Similarly, if a new
request with a greater priority is received, the
currently playing sound is stopped, and the new
request begins playing. 0 is the lowest priority, 100
is the highest priority.
Example :
S: IAC SB MSP2 SOUND clank.wav\0 P 100 IAC SE
(plays clank.wav at the highest priority)
S: IAC SB MSP2 SOUND dink.wav\0 P 0 IAC SE
(plays dink.wav at the lowest priority. If clank.wav were still
playing, this would be ignored)
Name : Continue
Code : C
Values : 0, 1
Default : 1
Used In : MUSIC
Description : Specifies whether the file should continue to play if
requested again, or if the file should restart.
Continuation is 1, restarting is 0. In either case,
any repeat count is reset to the new one.
Example :
S: IAC SB MSP2 MUSIC fugue.mid\0 L 0 50 IAC SE
(begins to play fugue.mid 50 times)
S: IAC SB MSP2 MUSIC fugue.mid\0 C 1 IAC SE
(the first fugue continues to play, but will not repeat)
S: IAC SB MSP2 MUSIC fugue.mid\0 C 0 L 0 2 IAC SE
(the fugue is interrupted and will start again, but will play
with two repeats)
Name : Type
Code : T
Values : string
Default :
Used In : SOUND, MUSIC
Description : Specifies the "type" of the music file. For example,
"combat", "zone", "death" or "clan". This is used
as a directory name for the file.
Example :
S: IAC SB MSP2 SOUND clank.wav\0 T combat\0 IAC SE
(plays combat/clank.wav)
Name : URL
Code : U
Values : string
Default :
Used In : SOUND, MUSIC
Description : Specifies the url of the sound or music file. This
parameter enables downloading of the file from the
server, although clients should always look to see if
the file has been downloaded already. Note that
wildcards make no sense when this parameter is used.
Example :
S: IAC SB MSP2 MUSIC f.mid\0 T e\0 U http://example.mud/sound\0
(plays e/f.mid from local directories if it was there, or
downloads http://example.mud/sound/e/f.mid, stores it in e/f.mid
and then plays it)
5. Default Specification
WONT MSP2
DONT MSP2
6. Security Considerations
There is a potential problem with the ability to spoof MSP2 messages
between clients. As per the Telnet protocol specification, any
input received that is 255 255 (IAC IAC) is treated as one single
255 character. This causes a potential problem whereby this input,
if transmitted directly to another client with no changes, can cause
telnet negotiations to be performed.
This can be avoided with careful programming, by simply duplicating
any instance of a 255 character to 255 255, upon normal output.
7. Acknowledgements
Thanks to Zuggsoft for writing the original protocol, and bringing
sound to the textual world.
Request For Comments Vision Codebase
March 2004
Mud Sound Protocol 2
Status of this Memo
This RFC descripbes a proposed Telnet option to allow a server to
tell a client to play music or sound files. Distribution of this
memo is unlimited.
1. Command Name and Option Code
Name = MSP2 (Mud Sound Protocol 2)
Code = 92
Name = MUSIC
Code = 0
Name = SOUND
Code = 1
2. Conventions used in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
In examples, "C:" represents lines sent by a protocol client and
"S:" represents lines returned by a protocol server. Indentation
and white space in examples is provided only to illustrate element
relationships and is not a feature of this specification.
In command descriptions, words enclosed in angle brackets are used
as variable name placeholders rather than literals. Braces are used
to group elements. In particular, braces with an ellipsis (…) show
a block that can be repeated. Finally, square brackets denote
optional parameters.
A string is a 0-terminated (i.e: a series of ASCII characters with a
trailing character of value 0) string. In protocol descriptions,
this terminator will be marked up as "\0".
3. Motivation for this option.
The genre of online text base adventures known collectively as
"Muds" has become somewhat stagnant, when it comes to displaying
information. Most muds are built from codebases which implement
only the basic fundamentals of the Telnet protocol. Notably, how to
say "No, I don't support that feature."
For this reason, clients have also become stagnant. Although
features such as mapping, aliases and triggered actions have become
popular, muds have had to remain as streaming text, left-to-right,
top-to-bottom, since many of the more "advanced" clients do not
support the full set of ANSI escape codes available to them. Thus,
it is almost impossible to tell what the output of a mud trying to
use these features will look like.
One or two muds have tried to break the mould by implementing their
output via an API such as "Curses" that uses these escape codes to
format the output of the muds. While this is a step in the right
direction, there are a few inherent problems.
During this period of stagnation, some other options have been
created to attempt to enhance the user experience. One of these is
the Mud Sound Protocol, a specification for which can be found (at
the time of writing) at http://www.zuggsoft.com/zmud/msp.htm. This
protocol assumes that the server outputs in line mode, yet with the
aforementioned ANSI escape code APIs, linemode does not exist.
Hence, the two do not interoperate.
This option intends to rectify that problem by reimplementing it
inside the telnet protocol, which can be separated easily from the
escape codes.
4. Command Meanings
4.1 Enabling Commands
S: IAC WILL MSP2
Sent by the Telnet Server to suggest that MSP2 be used, or
to agree to its use.
S: IAC WONT MSP2
Sent by the Telnet Server to refuse to use MSP2.
C: IAC DO MSP2
Sent by the Telnet Client to suggest that MSP2 be used, or
to agree to its use.
C: IAC DONT MSP2
Sent by the Telnet Client to refuse to use MSP2.
4.2 Subnegotiations
S: IAC SB MSP2 MUSIC <filename> [{<param1> <value1> …}] IAC SE
Sent by the Telnet Server to ask the client to play a
particular music file.
S: IAC SB MSP2 SOUND <filename> [{<param1> <value1> …}] IAC SE
Sent by the Telnet Server to ask the client to play a
particular sound file.
Filename is a string (see conventions) containing an optional path
to the name of a sound or music file. It may contain wildcards in
the form of at most one asterisk (*) and/or any number of question
marks (?). An asterisk can be used to match any number of
characters, whereas a question mark can match one and only one
character. If several matches are available after the wildcards
have been resolved, one is chosen at random.
4.3 Parameters
Name : Volume
Code : V
Values : 0-100
Default : 100
Used In : SOUND, MUSIC
Description : Sets the volume for this specific sound or music
invocation. 0 is minimum volume - muted. 100 is
maximum volume.
Example :
S: IAC SB MSP2 SOUND clank.wav\0 V 50 IAC SE
(plays clank.wav as a sound at half volume)
Name : Repeats
Code : L
Values : 0-65535
Default : 1
Used In : SOUND, MUSIC
Description : Specifies the number of times this sound or music
should be played. 0 is a special case where the sound
or music is played indefinitely, until instructed
otherwise. In the protocol, the value is specified
most significant byte first.
Example :
S: IAC SB MSP2 MUSIC bg.mid\0 L 0 44 IAC SE
(plays bg.mid 44 times)
S: IAC SB MSP2 MUSIC bg.mid\0 L 1 44 IAC SE
(plays bg.mid 300 times)
Name : Priority
Code : P
Values : 0-100
Default : 50
Used In : SOUND
Description : Specifies the priority of a soundbyte. If a new
request with an equal or lower priority is received,
the new request is ignored. Similarly, if a new
request with a greater priority is received, the
currently playing sound is stopped, and the new
request begins playing. 0 is the lowest priority, 100
is the highest priority.
Example :
S: IAC SB MSP2 SOUND clank.wav\0 P 100 IAC SE
(plays clank.wav at the highest priority)
S: IAC SB MSP2 SOUND dink.wav\0 P 0 IAC SE
(plays dink.wav at the lowest priority. If clank.wav were still
playing, this would be ignored)
Name : Continue
Code : C
Values : 0, 1
Default : 1
Used In : MUSIC
Description : Specifies whether the file should continue to play if
requested again, or if the file should restart.
Continuation is 1, restarting is 0. In either case,
any repeat count is reset to the new one.
Example :
S: IAC SB MSP2 MUSIC fugue.mid\0 L 0 50 IAC SE
(begins to play fugue.mid 50 times)
S: IAC SB MSP2 MUSIC fugue.mid\0 C 1 IAC SE
(the first fugue continues to play, but will not repeat)
S: IAC SB MSP2 MUSIC fugue.mid\0 C 0 L 0 2 IAC SE
(the fugue is interrupted and will start again, but will play
with two repeats)
Name : Type
Code : T
Values : string
Default :
Used In : SOUND, MUSIC
Description : Specifies the "type" of the music file. For example,
"combat", "zone", "death" or "clan". This is used
as a directory name for the file.
Example :
S: IAC SB MSP2 SOUND clank.wav\0 T combat\0 IAC SE
(plays combat/clank.wav)
Name : URL
Code : U
Values : string
Default :
Used In : SOUND, MUSIC
Description : Specifies the url of the sound or music file. This
parameter enables downloading of the file from the
server, although clients should always look to see if
the file has been downloaded already. Note that
wildcards make no sense when this parameter is used.
Example :
S: IAC SB MSP2 MUSIC f.mid\0 T e\0 U http://example.mud/sound\0
(plays e/f.mid from local directories if it was there, or
downloads http://example.mud/sound/e/f.mid, stores it in e/f.mid
and then plays it)
5. Default Specification
WONT MSP2
DONT MSP2
6. Security Considerations
There is a potential problem with the ability to spoof MSP2 messages
between clients. As per the Telnet protocol specification, any
input received that is 255 255 (IAC IAC) is treated as one single
255 character. This causes a potential problem whereby this input,
if transmitted directly to another client with no changes, can cause
telnet negotiations to be performed.
This can be avoided with careful programming, by simply duplicating
any instance of a 255 character to 255 255, upon normal output.
7. Acknowledgements
Thanks to Zuggsoft for writing the original protocol, and bringing
sound to the textual world.
20 Feb, 2009, Tyche wrote in the 35th comment:
DavidHaley said:
Well, as I said in #8, I'm not sure I see the point either. Why are subnegs being used here, if there is no first-class "negotiation" (i.e. communication) in the first place?
Well there is… The connecting client interested in the information sends IAC DO MSSP/NEW-ENVIRON. If the mud server responds WILL, then the client can request the information with the telnet subnegotiation. If the server doesn't respond or responds WONT, I presume the client would disconnect. Unless it wishes to continue with a fallback option…like a stat tracker client that would screen scrape a MUSH/MUX/MOO for numbers of players on and boot time.
20 Feb, 2009, Cratylus wrote in the 36th comment:
Tyche said:
The connecting client interested in the information sends IAC DO
This is the question I want Scandum to answer. What kind of
client did he have in mind? If it is a typical mud client,
the sort that people use to play muds, then this opt/neg
stuff makes perfect sense.
However I thought he was interested in the sort of client
that a listing site uses…for example, an expect script whose
only purpose is to connect, get info, and leave.
If this second kind of client was what he has in mind, as
the original post suggested to me, then this opt/neg
stuff is pointless.
In my opinion, if the focus is player mud clients and opt/neg
is used, then MSSP is pretty much DOA, since it'll by design
exclude loads of muds that won't/can't change to handle this
telnet option, AND it will be because we want to support
some tiny subset of people who will want this in their mud client.
It's just as easy for must muds to simply handle a query
string at login as it is to implement a MSSP opt/neg snippet.
For a large number of other muds, implementing a networking
change to handle MSSP opt/neg is just out of the question, whereas
just adding a query handler to the login sequence is trivial.
Therefore it just makes sense that if the idea is having
the largest number of muds adopt this, it should be similar
to the manner quixadhal described. A special string at login
from the listing site's query script, and a key/value table
response, and a disconnect.
And if it's going to be a simple query by a dedicated client,
then the telnet options/negotiation stuff just limits the
practical potential for widest adoption.
Assuming that this thing is meant to be widely adopted, of
course. But if it isn't, then I don't know why we're talking
about it.
-Crat
http://lpmuds.net
20 Feb, 2009, Scandum wrote in the 37th comment:
There is nothing that stops the client from sending:
IAC DO NEW-ENVIRON IAC SB NEW-ENVIRON SEND USERVAR IAC SE
Next wait a few seconds for the expected response, which wouldn't be much different from sending a special user name.
I could see it used by Zmud to automatically fill in the mud profile if the server sends IAC WILL NEW-ENVIRON, and naturally mud directories could add it to their crawlers as well.
My main concern with the NEW-ENVIRON option is the use of 0 bytes which might cause difficulty in string based scripting languages, so I think it'd be safer to grab a free slot and create a barebone set. This will also avoid telnet clients wasting bandwidth.
And as I said before, a lot of muds support MCCP, MXP, NAWS, etc, so it should be fairly easy for many servers to add.
IAC DO NEW-ENVIRON IAC SB NEW-ENVIRON SEND USERVAR IAC SE
Next wait a few seconds for the expected response, which wouldn't be much different from sending a special user name.
I could see it used by Zmud to automatically fill in the mud profile if the server sends IAC WILL NEW-ENVIRON, and naturally mud directories could add it to their crawlers as well.
My main concern with the NEW-ENVIRON option is the use of 0 bytes which might cause difficulty in string based scripting languages, so I think it'd be safer to grab a free slot and create a barebone set. This will also avoid telnet clients wasting bandwidth.
And as I said before, a lot of muds support MCCP, MXP, NAWS, etc, so it should be fairly easy for many servers to add.
20 Feb, 2009, Tyche wrote in the 38th comment:
I don't believe the intention of providing it to clients that are running lists or tracking stats precludes the use of the information it by a general mud client.
Yes, in order to have anyone adopt it, you'd pretty much have to code up implementations, snippets or submit patches for various servers.
I don't think the option is incentive enough itself for anyone to want to patch their mud to include it.
I've always thought that a more comprehensive package might be created that would be much more attractive and compelling.
For example, a package that included: NAWS, TTYPE, MCP, MCCP2, MSP, MSP2, MXP, ZMP, Pueblo and MSSP/NEW-ENVIRON all in one.
Yes, in order to have anyone adopt it, you'd pretty much have to code up implementations, snippets or submit patches for various servers.
I don't think the option is incentive enough itself for anyone to want to patch their mud to include it.
I've always thought that a more comprehensive package might be created that would be much more attractive and compelling.
For example, a package that included: NAWS, TTYPE, MCP, MCCP2, MSP, MSP2, MXP, ZMP, Pueblo and MSSP/NEW-ENVIRON all in one.
20 Feb, 2009, Cratylus wrote in the 39th comment:
Scandum said:
And as I said before, a lot of muds support MCCP, MXP, NAWS, etc, so it should be fairly easy for many servers to add.
I agree with this. I also say that it should be fairly inconvenient
for many servers to add. If you don't care about that, fine, but
if I were proposing a protocol for adoption I would tend to favor
wide adoption, especially if the point was gathering information
about lots of muds.
I assume you want to collect information about lots of muds. Your
scheme is more inconvenient than a simple string query would be.
Your scheme therefore would likely collect less information than
a string query scheme would. Your objective of wide data gathering
is subverted by the unnecessary use of telnet opt/neg.
I like the idea of an MSSP and would love to see it in action. That is
why I am commenting here. I'm not trying to shoot anything down. I just
happen to know how hard it is to get large numbers of people to
do things, through first hand experience. Asking them to implement
a system more complex than necessary is an easily avoidable error here.
Tyche said:
I don't believe the intention of providing it to clients that are running lists or tracking stats precludes the use of the information it by a general mud client.
I agree with this. And if having mud clients use it is the idea,
then it makes perfect sense. However, I would not spend my time
promoting such a thing, because I judge the value of its
usefulness to be vastly below the value of the effort. And since
I judge it to be so, I consider it a pointless distraction to
what could otherwise be a reasonably successful movement for
standardized mud surveying. Which I think would be awesome.
-Crat
http://lpmuds.net
20 Feb, 2009, Scandum wrote in the 40th comment:
Tyche said:
Lesbian Asian School Girls!
Scandum said:
I'm clueless what LASG stands for?
Lesbian Asian School Girls!
Hrm, that is indeed more important than total lines of script. I guess an "Adult" genre would have to cover it given the current puritan totalitarian oppression of anything related to sex, drugs, and libertarianism.
Tyche said:
I don't think the option is incentive enough itself for anyone to want to patch their mud to include it.
I think I'll check and see if I can add all the information zMud needs for its connection manager, which I guess should include a download address for a custom icon. If Zugg supports it that'd be a big step forward, and it'd be kind of cool if you connect to a mud with zMud and it automatically gets the icon and mud name right. I can add support for it to tintin which would be a useful tool for debugging MSSP for developers wanting to implement it (that would be another critical requirement where I think MSP2 failed), and perhaps someone to maintain a crawler if no major mud site is willing to add support for it to their crawlers. A list sorted by total online players ought to attract some of the bigger muds, and cheating muds should be easy to catch and ban.
Cratylus said:
I agree with this. I also say that it should be fairly inconvenient for many servers to add. If you don't care about that, fine, but if I were proposing a protocol for adoption I would tend to favor wide adoption, especially if the point was gathering information about lots of muds.
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. In fact, adding support would for MSSP would be trivial in that case.
Tyche said:
I've always thought that a more comprehensive package might be created that would be much more attractive and compelling.
I think ZMP was aiming to do that. If I remember correctly it messes up in the 0 byte and 255 byte department. Something like that would probably require a major client to bootstrap it, which pretty much comes down to zMud.
Random Picks
Isn't Unix time by default in UTC?
Unique as in prototypes, rather than objects. And a mud written in a scripting language would need a way to separately count area based scripts from other scripts, or skip the option if they find it irrelevant. Most Dikus don't have a noticeable amount of scripts and probably won't bother counting the amount of lines.
:redface: