Top Mud Sites Forum - View Single Post

shadowfyr · 06-21-2008, 02:20 PM

Lets be clear here. The *big* companies don't care, since they never intended the clients to run games or support anything other then the "basic" font. By definition, telnet has, until muds came along and people started trying to do wacky stuff with it, been solely a means to connect one text based interface to another text based interface, so that you can send commands to the remote system and get responses. Character support isn't needed, because, the presumption is that **both** ends are using the text mode of the graphics card, which has one single OEM font on it, which, unless you are using a MAC or some such, hasn't *significantly* changed since the first system that actually supported a full 8-bit character set, instead of 7-bit. The reason most are broken, is because there is *no* .TTF font that isn't also "broken" with respect to that original font. Most telnet game apps either use a .FON, which does have the right characters, or, if its real clever, it *may* use something like Lucida Console, and *translate* the codes for the high bit range into the correct UTF-8/unicode designations. However, *most* fonts don't support those characters.

Its what you get from having games that *still* operate using a single font, for the most part, still treat the font as though its the original OEM GPU font, but every fracking machine in existence now uses graphical systems, which employ *typesetter* fonts, which have *never* matched the OEM. It only gets worse when you actually "send" unicode, since then the client and server both need to know its being used, have the right font and correctly figure out "which" type of unicode is being used. And, that isn't broken telnet, that is broken unicode support, sitting "on" telnet.

The problem isn't telnet. Its just a means to get data from point A to point B, using a system that is stream driven, which things like HTML are not. HTML is "request driven", i.e., you have to "tell it", you are asking for the content, before server sends anything. Telnet opens a path, then just streams things, both ways. That is what you *want* for a game, unless you are going to have 4-5 different ports open, each talking to a different subservice on the server.

The **real** problem is, no one can both agree on a protocol to put on "top of" the stream to do more with it, *or* implement them right when they do. Zugg's MXP idea had some merit, but his own client doesn't fallow the specifications "as written", and nothing has come out of Nick Gammon's attempt to talk about whether its more reasonable to follow the precise specification, or allow it to remain broken. Result - Nick's client won't work for many muds out there, because they made it work with zMud, which ignores the part of the specifications that implies that "unrecognized tags" are **errors**, and that to display "text" containing a "<", you need to use &lt, not just dump something like, "<<Happy Fish Pond>>", in the middle of the stream of data.

What is needed is an agreement on how the fracking stuff should work, which isn't ambiguous, and some idea how or *if* a second port needs to be used for some data, and precisely "how" that information should be displayed, or integrated into the text window, if you allow that in the specification. Instead we have a dozen different, only rarely used, concepts, half the features of which are either not used, used wrong, or are so ambiguous in description that no one knows how they "should" work or interact with each other the right way. And, just to make things even dumber, since many people throw up their hands, decide they don't want to help find a solution, then just write their own "my server only" client (i.e. a custom one), and end up doing nothing but adding one more protocol to the mess, possibly not even documented any place other than on their own machine.

Telnet still works perfectly. Its the refusal of anyone adding to it to agree on anything, or come up with reasonably sane implementation specifications that makes it a disaster. And that includes the bozos that write unicode support that flat out doesn't work right, a problem you get, just as often, in applications that have nothing *at all* to do with telnet. All they do is buy/build some library that "looks like" it works right, in a few test cases, then argue that, "because we spent $5,000 to license this thing that doesn't work, it **must** work, so the problem has to be on you server, not our overpriced bug terrarium!"

06-21-2008, 02:20 PM	#36
shadowfyr Senior Member Join Date: Oct 2002 Posts: 310	Re: custom clients. Good or bad? Lets be clear here. The big companies don't care, since they never intended the clients to run games or support anything other then the "basic" font. By definition, telnet has, until muds came along and people started trying to do wacky stuff with it, been solely a means to connect one text based interface to another text based interface, so that you can send commands to the remote system and get responses. Character support isn't needed, because, the presumption is that both ends are using the text mode of the graphics card, which has one single OEM font on it, which, unless you are using a MAC or some such, hasn't significantly changed since the first system that actually supported a full 8-bit character set, instead of 7-bit. The reason most are broken, is because there is no .TTF font that isn't also "broken" with respect to that original font. Most telnet game apps either use a .FON, which does have the right characters, or, if its real clever, it may use something like Lucida Console, and translate the codes for the high bit range into the correct UTF-8/unicode designations. However, most fonts don't support those characters. Its what you get from having games that still operate using a single font, for the most part, still treat the font as though its the original OEM GPU font, but every fracking machine in existence now uses graphical systems, which employ typesetter fonts, which have never matched the OEM. It only gets worse when you actually "send" unicode, since then the client and server both need to know its being used, have the right font and correctly figure out "which" type of unicode is being used. And, that isn't broken telnet, that is broken unicode support, sitting "on" telnet. The problem isn't telnet. Its just a means to get data from point A to point B, using a system that is stream driven, which things like HTML are not. HTML is "request driven", i.e., you have to "tell it", you are asking for the content, before server sends anything. Telnet opens a path, then just streams things, both ways. That is what you want for a game, unless you are going to have 4-5 different ports open, each talking to a different subservice on the server. The real problem is, no one can both agree on a protocol to put on "top of" the stream to do more with it, or implement them right when they do. Zugg's MXP idea had some merit, but his own client doesn't fallow the specifications "as written", and nothing has come out of Nick Gammon's attempt to talk about whether its more reasonable to follow the precise specification, or allow it to remain broken. Result - Nick's client won't work for many muds out there, because they made it work with zMud, which ignores the part of the specifications that implies that "unrecognized tags" are errors, and that to display "text" containing a "<", you need to use &lt, not just dump something like, "<<Happy Fish Pond>>", in the middle of the stream of data. What is needed is an agreement on how the fracking stuff should work, which isn't ambiguous, and some idea how or if a second port needs to be used for some data, and precisely "how" that information should be displayed, or integrated into the text window, if you allow that in the specification. Instead we have a dozen different, only rarely used, concepts, half the features of which are either not used, used wrong, or are so ambiguous in description that no one knows how they "should" work or interact with each other the right way. And, just to make things even dumber, since many people throw up their hands, decide they don't want to help find a solution, then just write their own "my server only" client (i.e. a custom one), and end up doing nothing but adding one more protocol to the mess, possibly not even documented any place other than on their own machine. Telnet still works perfectly. Its the refusal of anyone adding to it to agree on anything, or come up with reasonably sane implementation specifications that makes it a disaster. And that includes the bozos that write unicode support that flat out doesn't work right, a problem you get, just as often, in applications that have nothing at all to do with telnet. All they do is buy/build some library that "looks like" it works right, in a few test cases, then argue that, "because we spent $5,000 to license this thing that doesn't work, it must work, so the problem has to be on you server, not our overpriced bug terrarium!"