Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > Advanced MUD Concepts
Click here to Register

Reply
 
Thread Tools
Old 09-26-2003, 03:44 AM   #1
erdos
 
Posts: n/a
Colored MUDs are split into two varieties: the type where the very first thing it asks is whether you want ANSI color; and the type where it goes straight to the main login screen, which is NEVER coloured regardless of color preferences.

And yet it is possible for the MUD to determine, without the player even being aware of it, what MUD client the player is using, and thus whether it supports ANSI.

But ANSI is just one example. Others would include determining whether the MUD should provide an artificial local echo, or whether the arrow keys get sent as characters (windows Telnet) or whether they are function keys for the client itself which never make it to the MUD (zMUD).

The vast, overwhelming majority of MUDs use the telnet protocol (even though the vast, overwhelming majority of MUD owners do not even know what the telnet protocol even is). The telnet protocol allows hidden client-server dialogues which the end user does not even see, which allow the server to determine many things, one of which is what type of program the player is using to log on (ie, their mud client).

Most MUDs, however, merely ignore this awesome capability, and if the client initiates one of those hidden dialogues (to ask whether it should use local echo, for example), most MUDs merely gag it and ignore it, without responding.

These days, alot of kids and teenagers do not know what "ANSI" is. If the weird text-based game is trying to solicit this info from them (which is totally unprofessional since, as I've shown above, it is unnecessary in most cases), they'll just say "screw it" and go play Everquest.
  Reply With Quote
Old 09-26-2003, 01:27 PM   #2
Stilton
Member
 
Join Date: Sep 2002
Posts: 100
Stilton is on a distinguished road
Quote:
Originally Posted by
The vast, overwhelming majority of MUDs use the telnet protocol
No, the vast majority of muds use broken text connections that look a little bit like telnet.  Many Dikurivatives (all ROM's for example), commercial custom servers like Achaea, and LP muds like BatMUD have all been guilty of seriously broken telnet implementations.

Many clients are even worse.

Quote:
Originally Posted by
Most MUDs, however, merely ignore this awesome capability,
As either a client or server author, you generally can't count on the other side of the connection behaving properly.  Thus manual configuration options for things like color, page length/width, etc.

Check out a few of the higher-quality muds and clients.  You'll find that they already do what you're proposing.

Edit: My sentence above is not intended to imply anything about the examples I mention earlier. Except maybe ROM

Stilton
Stilton is offline   Reply With Quote
Old 09-26-2003, 02:19 PM   #3
Treestump
Member
 
Join Date: Feb 2003
Location: Austin, TX
Posts: 40
Treestump is on a distinguished road
Send a message via AIM to Treestump
I bounced this question off of one of our coders, because I didnt know the answer and found the idea intruiging. Here is the response I received, in case anyone is interested.

Quote:
Originally Posted by
First thing to mention is that there isn't a standard Telnet protocol. That's kind of the beauty of the internet, folks recommend lots of changes but only the popular ones survive to make it into the "standard". It's kinda like that with terminal emulators too. Much of why we are at where we are now has to do with "ancient" history. Kids nowadays just don't understand.

Take the comments about echo for example. Telnet does have commands to request that local echo be turned off and on. It can't guarantee that will happen. In our game the only place we really use that is for the password entry (a common use). Some clients honor this request (Zmud), while others (my copy of mudmaster) do not. Just because telnet requests something doesn't mean it is honored.
-- In fact, the story of the player complaining about us not providing echo is a perfect point. For most folks the accepted telnet specification is for the server to tell the client to turn echo on and off (which we do). Kinda a historical example of why this may be is because not all terminal transmissions end up on a screen. Back in the day some would go straight to a printer (which is also where you get terms like carrage return and linefeed...to tell the printer what to do). Obviously it would be best if the owner of the printer was the one in control of what gets printed, and given that the sender already knows the data that was sent it's best if they handle the echo themself. Besides, it would just be a waste of bandwidth to do server echo (although some servers do support it).

Remember, telnet is not a fixed standard and it cannot force your client to do anything. It certainly can't gather information on the user like the program they are using, if it could hackers would go wild exploiting telnet holes. It is just a standardized way of sending communications, one that may or may not be followed.

So forget telnet. If it's mud features you care about then you really care about terminal emulation. We can send the data however, but once it gets to the user it needs to be displayed properly. For Necromium our official protocol is VT100 with optional ANSI color support. This means that our server is willing to negotiate VT100 escape sequences and if the user is capable we will also support ANSI escape codes. Sure, VT100 and higher terminals have a number of cool features,but the problem with this is that many of our users use clients that are not 100% VT100 implemented. In fact, a huge numbers use specialized "mud clients" that don't support the full set of commands. If we add features relying on VT100 we alienate a large segment of our community. Some advanced VT100 features are available (extended ASCII, the top prompt, etc...) but we can't make them standard because a large number of people don't support them. Even something as simple as blinking text (a common VT100 escape sequence) is not supported on a large number of terminals and when high level gods use it they should realize not everyone sees it blink (ironically, I am one of them).

That said, some VT100 implementations also involve our socket layer and how we process inputs. I won't bore folks with the ins and outs of select(), non-blocking sockets, pseudoterminals, etc... but let me say that the type of server you run is very dependant on what your users capabilities are.

So does this mean we can't reasonably utilize all the VT100 and TELNET features? Yes. Welcome to the limits of terminal gaming

So what now? The answer is simple. If we wish to offer client side features we have to write our own client protocol. And that's just what BoneZ is doing. You just can't take the current telnet/terminal user any farther.
Treestump is offline   Reply With Quote
Old 09-26-2003, 02:20 PM   #4
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,299
the_logos will become famous soon enough
Quote:
Originally Posted by (erdos @ Sep. 26 2003,03:44)
And yet it is possible for the MUD to determine, without the player even being aware of it, what MUD client the player is using, and thus whether it supports ANSI.
We just assume everyone can support ansi and turn it on automatically.

--matt
the_logos is offline   Reply With Quote
Old 09-26-2003, 03:44 PM   #5
erdos
 
Posts: n/a
Quote:
Originally Posted by
First thing to mention is that there isn't a standard Telnet protocol.
Yes there is.  RFC854, published in 1983.

Quote:
Originally Posted by
It certainly can't gather information on the user like the program they are using, if it could hackers would go wild exploiting telnet holes.
Exploiting telnet holes?  By knowing what client is being used?  This I've got to hear!  Your coder is right in that if your client is programmed to do so, it can ignore the request or even lie (many http bots lie and say they're Internet Explorer for example).  However, if you try logging onto your shell with zMUD, chances are good (although it depends on the shell) youll get a message something like, "No templates defined for zMUD".  Guess how the shell magically knew you were using zMUD.

Quote:
Originally Posted by
So does this mean we can't reasonably utilize all the VT100 and TELNET features? Yes. Welcome to the limits of terminal gaming
No.  You send the request for client type.  If you get no answer, or a client you don't recognize, do it the old way and manually ask the player for all the configuration preferences.  However, if the client responds that it is, indeed, zMUD, or Windows telnet, or putty, etc., act accordingly.  Your coder is certainly correct that there is no "one size fits all" solution when it comes to terminal gaming, but that's like forcing everyone who enters a shoe store to immediately have their feet measured no matter whether they need it or not, because of the few individuals who don't know their shoesize.
  Reply With Quote
Old 09-26-2003, 03:56 PM   #6
Ogma
Member
 
Ogma's Avatar
 
Join Date: Apr 2002
Home MUD: DartMUD
Posts: 86
Ogma is on a distinguished road
Even if you can determine what client a person is using and whether it is capable of displaying ANSI color or not, it is a bad idea to just automatically turn color on. Some people may not like your color scheme. That's a decision that should be left up to the user in my opinion.
Ogma is offline   Reply With Quote
Old 09-26-2003, 04:07 PM   #7
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
This is actually something that bugs the #### out of me. Years ago, 25 or more.., I used a program called Telemate. It didn't even have a clue what Telnet was, since it was a pure dial-up application for use with BBSs. However, one thing it had in common with nearly all such clients is that it expected any BBS using the ANSI spec to send it an ANSI sequence requesting to use ANSI and it replied with a can-do repsonse. Then I got on the internet and started to play muds. All of the sudden this 'basic' feature was missing. Why?

The one I play on right now uses ANSI, but you have to turn it on in the terminal options, because it won't send a 4-5 byte request the istant you connect to find out if you have ANSI. Others turn it on by default, which they can get by with because even MS telnet, which is the worst client in existance, as near as I can tell, recognizes the codes. Last I checked this is 2003, there is even extensions like MXP around that 3-4 programs use and 'require' negotiation to work properly, but muds can't do something that basic dial-up BBSs could do half a century ago. This isn't about telnet and what variation of it someone may be using, it is basic common sense imho. It make no sense at all that this isn't a standard feature of 'all' muds by now, no matter how old the code base.

Yes, there are some things that can't or won't work in specific instances, but something so silly and basic? As for things not supported, about the only major thing in VT100 not supported is things like text positioning. This is a trade off, most muds don't fake animation or graphics using these features, but send text that just continuously scrolls. A few do try to be clever and use it for things they could do without, at which point you run into a problem with about half or more of the clients, including Mushclient, which I use and is figthing it out toe to toe with zMud as the most versitile one around.

Well, some special text attributes and other tricks may not be either, but most of them are purely cosmetic, while color I would argue is so pervasive that not having it is practically a matter of basic function.

The blinking issue does bug me though. In Mushclient, the default is to treat blink as Italic, but that screws up maps. Supposedly this will get fixed in a 'much' later version, probably the same time a real port is developed that will run on Linux, though I haven't a clue how scripting will get implimented in that, since it currently relies on COM.
shadowfyr is offline   Reply With Quote
Old 09-26-2003, 04:12 PM   #8
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
The problem Ogma, is that it is a lot less confusing to people if they know there is color and merely need to turn it off or change it. If the first thing someone has to ask when 'all' of them log into a mud is, "Why isn't there any color?", you have done something wrong.
shadowfyr is offline   Reply With Quote
Old 09-26-2003, 07:29 PM   #9
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,299
the_logos will become famous soon enough
Quote:
Originally Posted by (Ogma @ Sep. 26 2003,15:56)
Even if you can determine what client a person is using and whether it is capable of displaying ANSI color or not, it is a bad idea to just automatically turn color on.  Some people may not like your color scheme.  That's a decision that should be left up to the user in my opinion.
Of course. The user can simply reconfigure the color scheme in any of our muds or turn it off. That should just be standard.

--matt
the_logos is offline   Reply With Quote
Old 09-27-2003, 01:23 AM   #10
vedic
Member
 
Join Date: Jan 2003
Posts: 39
vedic is on a distinguished road
Quote:
Originally Posted by (the_logos @ Sep. 26 2003,19:29)
Of course. The user can simply reconfigure the color scheme in any of our muds or turn it off. That should just be standard.
I don't agree with reconfigurable color schemes (or prompts, but that's another topic). A game has a much more cohesive atmosphere to it if everyone's look and feel are the same. Color is a big part of that. The trick is not to overdo it to the point where people want to change them around.
vedic is offline   Reply With Quote
Old 09-27-2003, 01:34 AM   #11
Teelf
Member
 
Join Date: Apr 2002
Location: Seattle
Posts: 32
Teelf is on a distinguished road
Quote:
Originally Posted by (erdos @ Sep. 26 2003,00:44)
And yet it is possible for the MUD to determine, without the player even being aware of it, what MUD client the player is using, and thus whether it supports ANSI.
It is possible in most cases, you are right.  The problem is that not all mud clients support telnet negotiations.  Most do not identify themselves.  And those that do can have that ID changed or removed by the user.  There is a document at http://cryosphere.net/telnet that breaks down client capabilities nicely.

I will add my agreement that the only way to gauruntee a feature you want is to code your own client or require one particular client.

Also, it is very safe to assume ANSI support.  I have yet to come across any client that does not at least trap and ignore escape codes.  This does not there is not one, of course.  But why worry about that .1%?
Teelf is offline   Reply With Quote
Old 09-27-2003, 02:15 AM   #12
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,299
the_logos will become famous soon enough
Quote:
Originally Posted by (vedic @ Sep. 27 2003,01:23)
Quote:
Originally Posted by (the_logos @ Sep. 26 2003,19:29)
Of course. The user can simply reconfigure the color scheme in any of our muds or turn it off. That should just be standard.
I don't agree with reconfigurable color schemes (or prompts, but that's another topic). A game has a much more cohesive atmosphere to it if everyone's look and feel are the same. Color is a big part of that. The trick is not to overdo it to the point where people want to change them around.
But you can't control what colors a player sees. First, colors look drastically different on different clients and monitors. They are not small differences either. Further, players can already just change the color scheme using their client so why not make it convenient for them by including it in-game? I know our players appreciate it.
--matt
the_logos is offline   Reply With Quote
Old 09-27-2003, 04:40 AM   #13
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Quote:
Originally Posted by
I don't agree with reconfigurable color schemes (or prompts, but that's another topic). A game has a much more cohesive atmosphere to it if everyone's look and feel are the same.
How can it possibly give the mud a more cohesive atmosphere? There's no way to know what other players prompts (or colour configurations) are, regardless of whether or not they are reconfigured!

I'm afraid I'll have to agree with the_logos on this one - I prefer a system whereby the player can configure their settings to whatever they feel most comfortable with (although I also like to have colour switched off by default).
KaVir is offline   Reply With Quote
Old 09-27-2003, 03:02 PM   #14
vedic
Member
 
Join Date: Jan 2003
Posts: 39
vedic is on a distinguished road
I don't think you understood what I was saying.

A few points:

1) If many clients allow the ability to recongifure what color is displayed when a specific color code is received (such as ZMUD) is it really necessary to have this available in the game server as well? If the player really wants to change the colors, they can do so with the client. But the game itself is sending out consistent information to everyone, so there's no question. Interpretation of that information is, of course, up to the client.

2) I'm not sure what you mean by "not knowing what the player's prompt is". Of course you know what it is, since the server is sending it to them. You may be talking about something else.

Obviously you should provide the ability to configure settings in the server that are necessary (such as turning of special text decorations for blind players, as an example). But color and prompt (again, I'm talking about the hp/spell point/stamina-type prompt) should be made uniform so that the interface is the same for all users. Room names appear in yellow, room descriptions in off-white, wilderness/ansi-mapped room color and icons appear the same, etc., for all users.
vedic is offline   Reply With Quote
Old 09-27-2003, 03:32 PM   #15
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,299
the_logos will become famous soon enough
Quote:
Originally Posted by (vedic @ Sep. 27 2003,15:02)
But color and prompt (again, I'm talking about the hp/spell point/stamina-type prompt) should be made uniform so that the interface is the same for all users. Room names appear in yellow, room descriptions in off-white, wilderness/ansi-mapped room color and icons appear the same, etc., for all users.
Again, you can't control this. You're insisting on sending players the same information but you have no control over how it's displayed to them by their client. So why is it so important that you send the same color codes if those codes impact players in different ways? Even without client-side coloring you can't control what colors the display and OS is spitting out. Ansi colors look drastically different on my different computers and clients. Different to the point of yellow looking distinctly orange on one of them, for instance.

The reason to add it into the mud server (assuming you're not requiring a custom client) is to provide a single interface for players to make the color and appearance changes. Your staff is then better able to help players do what they want because you only have to support one interface.

--matt
the_logos is offline   Reply With Quote
Old 09-27-2003, 04:12 PM   #16
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Gee.. The_logos, by that standard, why have any color at all, just assume that everyone is a genius at designing triggers and that everyone must be using zMud, Mushclient or some other program that lets you color your own text? Get real. most clients use only ANSI. In my experience there are only two effects this has, 1) some really bad clients start with a white background and 2) on some systems, with really bad displays, Yellow can end up looking Brown. The reality is that 'most' computers differ today only in how 'bright' the image is they produce. Colors tend to be more or less the same.

We are not talking about some stupid web browser that stupidly tries to match to the nearest 'valid' color according to your system. The display may not be 100% identical, but it is probably 98% identical, even in most worse cases. That said, you are probably talking about people changing the colors themselves? Fine, but often the only way to match a line, is if you can tell the client what color it was in the first place. You can tweak all the colors you like in some clients, but that is 'your choice' and if it screws something up in the game design, that is your fault for changing it. And as for MXP colors, as far as I know you can't easilly mess with them the way you can ANSI, so the biggest worry there is if the client can display them at all.

In any case, your own point about Yellow looking Orange on yours.. I have seen that on a Windows client, Imho, that client was not dsigned for games in the first place and you shouldn't use it for that. Same with drastically different colors on different systems. I doubt if you tried to display a full color photo on the same system that the result would e equally wrong, therefor it must be the client's fault and you should find a client that works right.

When you use ANSI, MXP, etc. you are making an assumption that 'most' people will see the right things. If someone is using an OS or client designed by Joe Screwup and won't show the colors right because he thought Puce looked better than Blue and Green was a horrible color no one should use, then you already have a serious problem. Same if you expect things to look right if you are using a horrid VGA monitor from the 1980's that can't display more than 256 colors and shows Yellow as Orange in text modes.

You may as well blame your difficulty seeing something on TV on the broadcaster, because you are using a black and white TV and the intensities of everything on the screen are all nearly identical. First use something that works the way the broadcaster 'intended' it to be seen, then complain about the content and what it looks like.
shadowfyr is offline   Reply With Quote
Old 09-27-2003, 04:20 PM   #17
the_logos
Moderator
 
the_logos's Avatar
 
Join Date: Sep 2002
Location: Mill Valley, California
Posts: 2,299
the_logos will become famous soon enough
Quote:
Originally Posted by (shadowfyr @ Sep. 27 2003,16:12)
Gee.. The_logos, by that standard, why have any color at all, just assume that everyone is a genius at designing triggers and that everyone must be using zMud, Mushclient or some other program that lets you color your own text?
You just answered your own question: Do it because everyone isn't a genius at designing triggers nor does everyone want to take the time to do it. Have color in your game and the ability to configure it in-game because you can provide for an easier interface for players to set the colors they want to see. Your game can group display items together in ways that a client cannot do without first being setup by the user. For instance, the client doesn't know the difference between an NPC and a player in a room until you tell it. The game knows it and can allow players to automatically color those in whatever color the users chooses.

Color in text is useful for highlighting or separating information. It is not the information itself 99% of the time so I'm unsure why you wouldn't provide an interface for players to set the colors themselves.

--matt
the_logos is offline   Reply With Quote
Old 09-27-2003, 06:45 PM   #18
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Guess I was a bit confused by your statement. Yeah, you should have some ability to configure. There are times though where it shouldn't be, but they are rare. In any case, the limitations of ANSI means that in most cases you will never get a decent set of options anyway. Color is not much more than a way to nicely seperate stuff out, in which case you have a limited number of options to do that anyway.

In any case, the point of all this started with why muds can't figure out something that is built into the ANSI protocal and has been used everyplace, except in muds, for the last 25 years or more. If you choose to turn them off or change them doesn't matter as much as either assuming that someone "doesn't" have color by default, or tht they 'always' have it. Both are wrong and a simple solution exists to figure it out, and you don't need to know what the specific name of the client is. ANSI itself has the means to find out built in.

However, between the two wrong choices, the one that makes you hunt through help files to turn on the color, instead of having it on to start, is more wrong than the other imho.
shadowfyr is offline   Reply With Quote
Old 09-28-2003, 04:28 AM   #19
erdos
 
Posts: n/a
Why all the color-specific threads?  Color is only one of the possibilities of making muds that follow the telnet standard.  Another couple examples:

1.  Identify which clients send the arrow keys through as characters (rather than reserving them as client function keys like zMUD) and allow these people to use them as server-side macros for moving around (up arrow = north, down arrow = south, etc.)  Particularly appealing for MUDs which use the worldmap code.

2.  Identify which clients follow the letter of the law when it comes to local echos, and go to town accordingly.  You could make it so, when they type "password oldpass newpass", it turns clientside echo off and provides serverside echo so that what they see themselves typing is "password ******* *******", even before they press enter.  Or you could be creative and make it so when people are highly drunk, they get their clientside echo disabled and the mud supplies a server side "slurred speech" version of local echo :-)

3.  Identify which clients have advanced features like rip or pueblo supported and use them accordingly-  or if you prefer to keep that optional, it still has the advantage that people who play on zMUD at home and Windows telnet at work can have the rip at home but at work the server sees they're on Windows telnet and doesn't send it (ever logged on a RIP account from a non RIP client?  not pretty!)

4.  Make it so when players on applicable clients hit the "break" key, it unqueue's all their queued up commands (for people who type "trance" 15 times then suddenly get ambushed)

5.  In some cases, be able to determine the window size of the player's client.  I'll leave you to imagine the possibilities.

6.  If a client supports environmental variables, these could be used to reduce RAM load on the server of very specific data (things of little urgency that we dont mind people being able to hack or lose)

Anyway, I'm just trying to get some new ideas circulating, it seems a long time since the community has had much in the way of new ideas :/   Don't mean to start any flamewars
  Reply With Quote
Old 09-28-2003, 09:58 AM   #20
vedic
Member
 
Join Date: Jan 2003
Posts: 39
vedic is on a distinguished road
Quote:
Originally Posted by
Color in text is useful for highlighting or separating information. It is not the information itself 99% of the time so I'm unsure why you wouldn't provide an interface for players to set the colors themselves.
Sounds like you're underestimating the value of color in a game. Color can speak volumes - warn players with bright red text, put channels in magenta, put player-to-player conversation in cyan, etc. - it's part of the feel of a game, regardless of whether or not the colors display exactly the same on every computer. The fact is that 99% of the time, they'll be close enough to what you intended to have an impact.

Additionally, colors in terrain maps play an important role, such as blue for water and cyan for reefs or shallows, for instance. I think there's a point where you can focus too much on the interface and giving players commands to change anything.

I'm not saying that lots of configuration is a horrible thing, just that I don't agree with it, and I've given my reasons why. The entire reason I started this tangent is because the_logos stated that every game should have this ability as a standard, and I don't agree. I think it's more of how you see the game.

Just as authors wouldn't want people changing text or words in their novels, I see the look and feel of a game as essential to the final vision of the product. That includes color. True, you can't control entirely how it will look at the other end, but you can come close. Perhaps I am pickier about that than most.
vedic is offline   Reply With Quote
Reply


Thread Tools


Why not exploit the telnet protocol? - Similar Threads
Thread Thread Starter Forum Replies Last Post
Beyond Telnet Rathik Advanced MUD Concepts 52 09-01-2006 01:21 AM
Telnet Options? Raewyn MUD Coding 1 02-05-2006 09:58 AM
Telnet Negotiations Khadgar MUD Coding 6 01-09-2006 09:02 AM
PTP (pfile transfer protocol) visko MUD Coding 20 07-20-2002 08:19 PM
Cant type in telnet window! Chobbie Newbie Help 2 07-17-2002 02:38 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 02:11 AM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014