16 Jun, 2014, plamzi wrote in the 41st comment:
Votes: 0
quixadhal said:
Scandum said:
Most clients and servers ignore the TTYPE standard, rightfully so because it's highly impractical.

No real point in discussing specific behavior as programmers will do whatever they please.


Yeah, since there are some people who just blow through stop signs at intersections, it's stupid for anyone to bother stopping.


Poor analogy. Protocols are a lot more like human languages, in that they facilitate communication, and some are much less popular than others.

Protocols are a lot less like traffic rules, especially the ones regulating traffic at an intersection. There are many contexts in which trying to "speak" a quant protocol is simply more trouble than it's worth, and is more akin to "stop, get out of the car, and perform 10 cartwheels before you proceed to cross the intersection".
17 Jun, 2014, Scandum wrote in the 42nd comment:
Votes: 0
SlySven said:
The esteemed Scandum said:
No real point in discussing specific behavior as programmers will do whatever they please.

Maybe so, but if I can make the Client I'm coding for get it right I'd like to do so - just so long as I understand what is right!

Mudlet is neither XTERM-256COLOR, XTERM, or ANSI compatible when going by the official TTYPE protocol. ANSI compatibility would mean supporting most ANSI escape codes and Mudlet only supports the color codes as far as I know.

XTERM-256COLOR means the terminal emulates XTERM as well as the 256 color extension, Mudlet doesn't emulate XTERM, just 256 colors, so it shouldn't identify itself as such.

Hence the MTTS standard to provide some common terms and what they should mean to MUDs.

As far as I know many clients ignore the restrictions on special characters, so it's impossible to enforce.
17 Jun, 2014, quixadhal wrote in the 43rd comment:
Votes: 0
So, "mudlet" supports the xterm-256color extensions without actually supporting the basic xterm functionality?

How about using XTERM-256COLOR-BROKEN ?

Seems to me that you're designing the protocol to account for broken and incorrect use. That's a sure way to ensure the protocol is never correct. Surely a smarter way is to expect a proper response from the client and TELL THEM THEY'RE BROKEN if they, in fact, send incorrect data?

"Hi! I see you told me you supported FOOTERM-BUBBLESQUEAK, but I have no idea what that is, so I'm going to assume ANSI. Please either add a support terminal type identifier to your client's response, or send us the terminal definitions for FOOTERM-BUBBLESQUEAK, so we can add support for it. Thank you!"

Many people using FOOTERM (which probably does ANSI anyways) will probably complain at the author about the obnoxious message they see EVERY TIME they log in. Hence, perhaps, getting the author to correctly follow the standards and return FOOTERM-BUBBLESQUEAK, followed by FOOTERM, followed by ANSI.
18 Jun, 2014, Scandum wrote in the 44th comment:
Votes: 0
quixadhal said:
So, "mudlet" supports the xterm-256color extensions without actually supporting the basic xterm functionality?

The basic xterm functionality is far from basic.

The original protocol doesn't work and never will.
18 Jun, 2014, alteraeon wrote in the 45th comment:
Votes: 0
Quixadhal wrote:

Quote
Seems to me that you're designing the protocol to account for broken and incorrect use. That's a sure way to ensure the protocol is never correct. Surely a smarter way is to expect a proper response from the client and TELL THEM THEY'RE BROKEN if they, in fact, send incorrect data?

Telling them they're broken is going to magically fix what exactly? A lot of players are using binary clients which were built ten or more years ago. Telling those players that their client is broken is equivalent to telling them to go play elsewhere.

Alter Aeon MUD
http://www.alteraeon.com
18 Jun, 2014, quixadhal wrote in the 46th comment:
Votes: 0
alteraeon said:
Quixadhal wrote:

Quote
Seems to me that you're designing the protocol to account for broken and incorrect use. That's a sure way to ensure the protocol is never correct. Surely a smarter way is to expect a proper response from the client and TELL THEM THEY'RE BROKEN if they, in fact, send incorrect data?

Telling them they're broken is going to magically fix what exactly? A lot of players are using binary clients which were built ten or more years ago. Telling those players that their client is broken is equivalent to telling them to go play elsewhere.

Alter Aeon MUD
http://www.alteraeon.com


Yeah, and let them go. If they can't be bothered to send an email to help fix the problem THEY ARE COMPLAINING ABOUT (Namely, that my MUD gets their terminal type wrong because their client sends nonsense), they can either live with it not working right or go play somewhere else that will just silently do things wrong.

You know what happens when you coddle people at every turn? You get people who can't function without coddling.
18 Jun, 2014, plamzi wrote in the 47th comment:
Votes: 0
In situations where a client is free, or no longer developed, or not supported for any other reason, telling people to shoot emails into the void is probably not going to build anyone's character. Steering players to better clients, or even better, a customized client, shows that you care. If they choose to ignore your advice, as a game admin, you should still care more about retaining players than about being protocolically anal.
18 Jun, 2014, Hades_Kane wrote in the 48th comment:
Votes: 0
alteraeon said:
Quixadhal wrote:

Quote
Seems to me that you're designing the protocol to account for broken and incorrect use. That's a sure way to ensure the protocol is never correct. Surely a smarter way is to expect a proper response from the client and TELL THEM THEY'RE BROKEN if they, in fact, send incorrect data?

Telling them they're broken is going to magically fix what exactly? A lot of players are using binary clients which were built ten or more years ago. Telling those players that their client is broken is equivalent to telling them to go play elsewhere.

Alter Aeon MUD
http://www.alteraeon.com


I'm very much inclined to agree. As a player, if I encounter a MUD for the first time that is bombarding me with "your client sucks and is broken" messages when every other MUD I play or have tried isn't, I'm going to be much more likely to figure the MUD itself is what is broken and just go find somewhere else to play. My first login, what incentive do I have to try to stick with this game? None at all, I have no time invested into it at all. It's a no brainer people will just leave.

And as a player, I can also very much say that people get very, very attached to their preferred clients, and generally speaking, and most veteran MUDers I know would rather use their 10+ year old client because it's what they are used to and attached to, then adapt to another client for a specific game. I even have a flag in my game to accommodate the still very large amount of Gmud users whose client incorrectly identifies dark and bright white.

What is more important, a game that works for your players, or being anal about being "right" about something that doesn't really matter?

It's not like most MUDs these days have players beating down their doors wanting in to play; it's important to try to be as accessible as you can while not sacrificing the integrity of the vision of your game, or you'll have a technically sound game following all proper protocols but missing one key thing: players.
19 Jun, 2014, quixadhal wrote in the 49th comment:
Votes: 0
That's where we have a difference of opinion in how the solve the problem.

You guys seem to think it's vital to do whatever it takes to preserve each and every player, because if they leave it's IMPOSSIBLE to replace them. As a result, our games become less and less focused, and drift further into antiquity because we fear to "annoy" those old codgers who are used to firing up tinyfugue from their bash prompt.

This is a self-fulfilling prophecy. The more you try to keep supporting broken clients, the more you ensure that everything remains broken and outdated. Every time you refuse to use a standard because it might break things for someone, you break things for NEW developers who might want to make something, but won't because they don't want to code workarounds for every broken thing out there.

I'm of the opinion that if your GAME is any good, your players will adapt to whatever changes you require them to make (assuming they can… obviously, a blind player isn't going to use a graphical client), because they enjoy playing your game. If breaking their crufty old client makes them go elsewhere, maybe your game wasn't as compelling as you hoped.

Also, nowhere did I suggest preventing them from playing. However, having a message scroll by when they login that reminds them that their client is broken, and that issues they have are THEIR FAULT for using it, doesn't seem like a bad thing. It certainly seems better than having them pester your admins about "bugs" that are caused by their client, not the MUD's code.
19 Jun, 2014, Splork wrote in the 50th comment:
Votes: 0
quixadhal said:
I'm of the opinion that if your GAME is any good, your players will adapt to whatever changes you require them to make (assuming they can… obviously, a blind player isn't going to use a graphical client), because they enjoy playing your game. If breaking their crufty old client makes them go elsewhere, maybe your game wasn't as compelling as you hoped.


Our game has been running for over two decades. If we forced everyone to use our custom client, my guess is we would lose half of our playerbase. I don't know any mud which would survive forcing players to abandon software they have used for decades and have grown to love. I've always said that its easier for players to change games than it is to change clients.

I see absolutely zero downside to supporting whatever the players want to play with, guess I am in agreement with most others here…
19 Jun, 2014, Hades_Kane wrote in the 51st comment:
Votes: 0
Quote
I'm of the opinion that if your GAME is any good, your players will adapt to whatever changes you require them to make


That's good in theory, but I would be willing to bet that the majority of experienced players (which is really the vast majority of the player pool out there) will simply leave a game and try something else before even giving it a chance to see if it's any good if they are forced to change clients.

You can't tell a game is any good by the login screen, you can't tell if it's any good by the end of character creation, and you likely can't get a good feel on it by the end of whatever newbie tutorial there is (you can certainly tell a bad game pretty quick, but that's a different story).

If you've added in things that effectively aims to annoy the player into switching into a new client, you will far more likely annoy them into a different game than doing what you are aiming to do because the player, by this point, has no incentive or investment into the game to switch clients or give the game a chance beyond that point to find out if it is any good.

And this isn't about "do[ing] whatever it takes to preserve each and every player". Quite frankly, we don't, and I've been the first to tell players asking for something our game isn't designed for to try another MUD.

I'm not adding in magicite, materia, remort, increasing exp gains, lowering the cost of potions, making boat travel take less time, adding in Burmecian as a playable race, adding the clan you just applied for when you've been in the game for 2 days and have no real concept of the power balance and structure of the game world…

But purposely annoying quite possibly a large quantity of your potential playerbase just because you have some principal about forcing client designers to follow better protocol will only serve to alienate your potential players, because they are going to be MUCH more likely to abandon your game before giving it a fair shot, then taking the time to email a developer that won't likely even bother to respond, much less patch his client to make it work with your game. And even if they emailed the developer, it doesn't automatically make your game playable as you intended, and that player is still having to deal with whatever annoyances you've added even if they "did the right thing"… or they are forced to switch clients, which a significant chunk of players simply are unwilling to do.

I'm fine being "part of the problem" if it means not potentially alienating a vast majority of my possible playerbase.
20 Jun, 2014, SlySven wrote in the 52nd comment:
Votes: 0
Well I sat down and put together an (even longer and rambling) response to some previous posts but I'll try to distil what my concerns are about MTTS as it is currently defined and what the issues that I'm having intersect with that:
In the MTTS specification it said:
Mud Client Name
As RFC1091 details the server can request TTYPE information using sub-negotiations. On the first TTYPE SEND request the client should return its name, preferably without a version number and in all caps.
RFC1091 mandates that the first TTYPE SEND should be the most detailed and specific terminal information and that subsequent ones, if referring to the same terminal are more and more generic equivalents; as I see it this means that a version number (if available) SHOULD be included, indeed I propose for Mudlet to include a build suffix as well if there is one, on the first TTYPE SEND, a subsequent TTYPE SEND then would return just the client name and version and only on the one after that would just the client name be sent. So either two or three sends will begin with the client name "MUDLET" depending on whether it is a release or development build. This fits in with the RFC but the MTTS only expects the most generic client name. I think MTTS is wrong in this regard, it cannot demand a specific number of responses (three:)
  • Client name;
  • Some 'generic' terminal that the client only partially matches and does not precisely match or which is not suitable to actually;
  • The MTTS response
because claiming to be a "DUMB" terminal, which this one might have to unless it is reaches all the requirements to be called ANSI is not something that most users are likely to want to actually use - claiming to be "DUMB" must disable handling any color information unless we get to the MTTS entry which if the server only makes a limited number of requests might not happen!

The rationale for my proposed direction in this will actually to assist server operators as it means that if there is an issue that MUD operators are trying to resolve with MY client then if they receive a TTYPE of e.g. "MUDLET-3-0-1-BUG-ECHOTEST" they can tell that this is, for instance, a test version trying to nail down an ECHO bug and that they might engage a different bit of code that they have cooked up to resolve something on their end which might be something that is not yet ready for testing on their main player-base. If the server code is not specifically looking for such a response and can't understand the build information then the next response, with just the version in it's Major-Minor-Release form, might be what they want to parse (and what they are likely to get in the future) so they will know that "MUDLET-3-0-2" will have differences compared to the current "Mudlet 2.1.0" that is out in the wild, or if they don't really want that much detail the final "MUDLET" will tell them just what they want to know. If they are a fan of Mudlet a sysOp might even consider rolling a special version for themselves by setting the BUILD variable in the src.pro file to "-Godmode" so that their server can respond in a custom manner when a client returning "-GODMODE" as the tail end of the first TTYPE response but that is a side issue… :wink:

Quote
Mud Terminal Type Standard
On the third TTYPE SEND request the client should return MTTS followed by a bitvector. The bit values and their names are defined below.
Is there a space separator between MTTS and the number, if so, I reiterate, this is NOT compliant with the RFC, the only valid options are: the number starts immediately with the first digit as the next character or one of '-' or '/' may be used. I know that past and current versions of Mudlet have got it wrong and used a space between MUDLET and the version string and used invalid '.' characters in its single, static TTYPE response but I'm fixing that going forward so SysOps will start to see the right thing from us…

Quote
1 "ANSI" Client supports all ANSI color codes. Supporting blink and underline is optional.
2 "VT100" Client supports most VT100 codes.
4 "UTF-8" Client is using UTF-8 character encoding.
8 "256 COLORS" Client supports all xterm 256 color codes.
16 "MOUSE TRACKING" Client supports xterm mouse tracking.
32 "OSC COLOR PALETTE" Client supports the OSC color palette.
64 "SCREEN READER" Client is using a screen reader.
128 "PROXY" Client is a proxy allowing different users to connect from the same IP address.

The client should add up the numbers of all supported terminal capabilities and print it as ASCII in decimal notation. In the case that a client supports ANSI, UTF-8, as well as 256 COLORS, it should respond with "MTTS 13", which is the sum of 1, 4, and 8. The reporting of UTF-8 should be implemented as a user setting, unless the client is certain that a Unicode font is being used.
"…print it as ASCII…" I recall that you have talked about going beyond a theoretical 255 maximum value but until then it might NOT be immediately clear to people if the value to present is a single "octet" (as is used to encode values between 0 to 255 in other places in various bits of Telnet) or a series of ASCII digit characters '0' to '9' inclusive. Also by "…decimal notation…" I take it you actually mean a number IN BASE 10 rather than a number with an explicit decimal point (as '.' are not allowed in the TTYPE value) or a number in hex!

Quote
Cycling
RFC1091 allows for cycling through a list of terminal types in order to select one. Implementing this behavior is optional, but the client must properly report the end of the cycle.
At the fourth TTYPE SEND requests the client should repeat the previous response, reporting MTTS followed by a bitvector. Receiving the same terminal type twice indicates to the server that the end of the list of available terminal types has been reached. If the server sends additional requests the client can either continue to respond with MTTS <bitvector>, reset its cycling state to the initial state and start over, or ignore the request.
If the server sends IAC DONT TTYPE the client's cycling state should be reset to the initial state, as if the client just connected to the server. This behavior allows recovering from a copyover.


I can add MTTS to Mudlet - once I work out which value to return - but I will not guarantee that it will be the result obtained after the third and fourth request for a TTYPE response, only that it will be the last, repeated, one.

Quote
Proxies
It's suggested for proxies adding MTTS support to also implement the NEW-ENVIRON telnet option as per RFC1572. Using the NEW-ENVIRON option the server can send: IAC SB NEW_ENVIRON SEND VAR "IPADDRESS" IAC SE. When receiving this send request the proxy should respond with: IAC SB NEW_ENVIRON IS VAR "IPADDRESS" VALUE "<user's ip address>" IAC SE.
The quote characters mean that the encased word is a string, the quotes themselves should not be sent.
Actually there is an error here, "IPADDRESS" is NOT a "well known" variable that the subcommand VAR (=0) can refer to (they are listed as: USER, JOB, ACCT, PRINTER, SYSTEMTYPE and DISPLAY). One could take the first part of the last variable which is the (X) Display variable formatted: "<host>:<dispnum>[.<screennum>]". Instead the subcommand USERVAR (=3) is what should be used.

I also read somewhere that NEW_ENVIRON should be negotiated BEFORE BINARY, TTYPE and EOR negotiations are concluded but that is a detail I'm not going to worry about here.

Incidentally I was wondering whether any server using this NEW_ENVIRON information (utilising a snippet of code to do so) has checked it would respond correctly if they got an IPv6 address instead of an IPv4 one but hey that's another bridge to burn… :evil:

As I've said before - I want get it right and I think these things need to be sorted before MTTS is really right, I do think it could be useful if clients can present a uniform idea of what their capabilities are and in some ways it compliments telling the server explicitly what the client's name is. It means that new unknown clients can present an idea about what they offer to servers that would not be able to tell, whereas "well known" clients can be handled by name - and if they present version information in the manner I suggest they can be as explicit as the servers might wish.
22 Jun, 2014, Scandum wrote in the 53rd comment:
Votes: 0
If you follow the TTYPE specification Mudlet can't call itself ANSI, following the MTTS standard it can.

MTTS doesn't restrict the use of spaces and other special characters. I don't see any valid reason for why they should be restricted, other than 'the specification says so'.

The MUD community decides what a "well known" variable is, not some specification that hasn't been updated in 20 years.

I don't know of any MUD servers that want to do anything with a client's version number. I guess the full client name and version could be communicated using NEW-ENVIRON. CLIENTNAME and CLIENTVERSION could be requested.
22 Jun, 2014, quixadhal wrote in the 54th comment:
Votes: 0
It certainly CAN call itself ANSI. Maybe you should re-read the RFC.

In particular, Mudlet should be returning a sequence of values, starting with MUDLET-22 (or whatever version it is), then MUDLET, then MXP, then ANSI. Insert anything else it supports in the appropriate place, depending on how generic or specific it is.

As to what servers do with version information… assuming any MUD server were coded to actually SUPPORT things, rather than half-a**ing it and hoping for the best, would be to enable or disable features based on the client's idenfication. If you know MUDLET supported a particular feature as of version 12, and the client reports version 10, you'd disable that feature so it doesn't break their client's display.

Just because *YOU* don't know of any use for part of a protocol, doesn't mean the people who designed the protocol didn't have a use for it.
22 Jun, 2014, Scandum wrote in the 55th comment:
Votes: 0
MXP is enabled with the MXP telnet option, not with TTYPE. So you'd be violating the MXP standard by trying to do so.
22 Jun, 2014, quixadhal wrote in the 56th comment:
Votes: 0
Perhaps so, but that's a different issue that has no bearing on the TTYPE negotiation. If I have a terminal that supports MXP and NOT anything else, it's perfectly legitimate to send that as a TTYPE response. It's up to the server to properly USE that information by initiating the MXP negotiation. TTYPE is meant to provide information to the server about the client's capabilities, not to impose the use of one or more of the options listed.

The point of providing multiple TTYPE responses is to allow the server to pick the one it supports the best, of the list the client is claiming to support. If I see "vt220", "vt100", and "ansi", I know I can use extended line drawing characters and double-width/double-height characters if I use the vt220 feature set. If my server doesnt' use those, or doesn't know anything about it, that's fine… there's nothing wrong with using vt100 or ansi instead. The client *claims* it supports all three of those.
23 Jun, 2014, Scandum wrote in the 57th comment:
Votes: 0
The client should probably report itself as DUMB in that case, as is technically the case for most mud clients, including mushclient and mudlet.

The MXP negotiation should be send when the client connects. I guess you could communicate it over TTYPE, but it'd be pointless. It'd be a silly recommendation in my opinion.

Very few terminals support VT100 line drawing. All the notable terminals try to emulate XTERM, so that's the standard.
23 Jun, 2014, SlySven wrote in the 58th comment:
Votes: 0
Agreeing with quixadhal: actually, trying to find a definitive statement as to what the requirements to identify something that can cause itself ANSI is a non-starter. The best I can get is ECMA-48 version 5 which Wikipedia notes was adopted by ANSI as ANSI X3.64 in 1981 and withdrawn in 1997. Even the producers of this document note: "The devices to which this Standard applies can vary greatly from each other depending on the application for which a device has been specifically designed. It is technically and economically impractical for one device to implement all the facilities specified in this Standard." So Mudlet might do only a small number and still use the "ANSI" terminal type legitimately - though I guess we had better make sure we document what those ARE…

In regard to MTTS it would seem to me that there MUST be an minimum subset of control sequences that has to be explicitly listed in the specification as being required in a Client which it MUST have to set the ANSI bit value - so Server coders have a maximum set of control sequences that they can use. This will help to guarantee interoperability with a new client that is not explicitly known by name to them - which seems to me to be what MTTS is all about.

Moreover MTTS can only legitimately "hang on the shirt-tails" of the TTYPE sub-option if it follows the rules of that. My best guess is that TTERM codes might have been passed around as arguments between various operating system elements, some of which use a space (or indeed '-' or '/') character as a delimiter or something with special meaning (which is why the latter pair cannot appear as the first or last character), this may also be why it is case insensitive as some antiquated (and some not so old) OSs have limitations in that reguard. So I'll declare here and now that if I try and code in for MTTS, I'll code Mudlet to use a '-' and not a space between MTTS and the number value, whatever that might actually work out to be.

I'd still like to know more about what a 'proxy' is defined as being as per MTTS!

In regard of the use of Telnet sub-option New Environment:
Scandum said:
The MUD community decides what a "well known" variable is, not some specification that hasn't been updated in 20 years.

in RFC1572 it is said:
5. Well Known Variables

USER This variable is used to transmit the user or account
name that the client wishes to log into on the remote
system. The format of the value the USER variable is
system dependent, as determined by the remote system.

JOB This variable is used to transmit the job ID that the
client wishes to use when logging into the remote system.
The format of the value the JOB variable is system
dependent, as determined by the remote system.

ACCT This variable is used to transmit the account ID that the
client wishes to use when logging into the remote system.
The format of the value the ACCT variable is system
dependent, as determined by the remote system.

PRINTER This variable is used to identify the default location
for printer output. Because there does not currently
exist a standard way of naming a printer on a network,
the format of this variable is currently undefined.

SYSTEMTYPE This is used to transmit the type of operating system on
the system that sends this variable. It value is
identical to the value of the SYSTEM (SYST) command in
FTP [4]. The format of the value shall have as its first
word one of the system names listed in the current
version of the Assigned Numbers document [5].

DISPLAY This variable is used to transmit the X display location
of the client. The format for the value of the DISPLAY
variable is:

<host>:<dispnum>[.<screennum>]

This information is identical to the information passed
using the Telnet X-DISPLAY-LOCATION option. If both the
DISPLAY environment variable, and the X-DISPLAY-LOCATION
option [6] are received, and they contain conflicting
information, the most recently received information
received should be used.

Because it is impossible to anticipate all variables that users may
wish to exchange, the USERVAR type is provided to allow users to
transmit arbitrary variable/value pairs. The use of an additional
type allows implementations to distinguish between values derived by
the remote host software and values supplied by the user. Paranoid
implementations will most likely treat both types with an equal level
of distrust. The results of a name-space collision between a well-
known and a user variable are implementation specific.
Note that last paragraph, it describes how the writers know that other variables would be wanted, so perhaps the reason it hasn't been changed in twenty odd years is because it didn't need to be?
20 Aug, 2014, Scandum wrote in the 59th comment:
Votes: 0
MUSHclient added MTTS support (v4.93) which can be used to detect 256 color and UTF-8 support (if enabled). I assume it also reports ANSI color support.
28 Sep, 2014, Scandum wrote in the 60th comment:
Votes: 0
Looks like mudportal.com added MTTS support some months back. It reports the PROXY flag, and also reports IPADDRESS through the NEW-ENVIRON telnet option.
Random Picks
40.0/65