So after doing some research on what's available, I'm going ahead with writing a new RFC 854 conforming Java telnet lib with mud protocols. I'm not planning on covering everything, but MCCP, MSSP, and MSDP are on the list.
I'm going to use it for my own game, but also try to make it modular enough that someone can adapt it for their own use. It may not be just plug and play, but since a lot of the work I'll be doing involves pulling out the useful telnet stuff from other codebases, I'm hoping this lib will make it easier on anyone else down the road.
One suggestion for an additional protocol you might want to include, I3 support.
The I3 "intermud" network is of arguable use or merit, but many people like to have their muds connected… especially these days when a typical MUD is a lonely place. I3 was developed for LPMUD type games using the MudOS game driver, which had a "feature" called a "mudmode socket".
All that is, is a tcp socket which sends LPC data structures (serialized) with a length prefix and trailing NUL byte. While your library would not be expected to handle the I3 protocol itself, being able to serialize java objects into LPC structures and back, and automatically handling that length word would make implementing I3 in future java games less annoying.
I know it's not part of TELNET, but it is MUD related and since you're doing MCCP, it seems like it would be a useful addition, or perhaps a parallel class that would reuse much of the same code.
So after doing some research on what's available, I'm going ahead with writing a new RFC 854 conforming Java telnet lib with mud protocols. I'm not planning on covering everything, but MCCP, MSSP, and MSDP are on the list…
How bad is TELOPT/protocol support in existing Java codebases like CoffeeMUD?
@plamzi, Coffee does implement msp, mxp, MSDP and GMCP, i3 and imc2 (see https://github.com/bozimmerman/CoffeeMud... ). I'm not sure about other general telnet telopts. However some of these implementations seem closely bound to Coffee-specific game logic and assumptions.
No doubt Coffee will be a valuable reference though; I also forgot to add groovymud to the references,
I don't actually know how good or bad CoffeeMUD's TELOPT support is, but Bo and I had an exchange, years ago.
I pointed out that he was sending DikuMUD style backwards line endings (LFCR), rather than following the TELNET standard of CRLF, and provided the RFC in question to show where and why it was defined that way. He pretty much dismissed me by saying "MUD's don't use TELNET, they have their own *standard*".
So, given that, I wouldn't hold my breath for CoffeeMUD having a properly done TELNET stack. But, feel free to look. :)
I pointed out that he was sending DikuMUD style backwards line endings (LFCR), rather than following the TELNET standard of CRLF, and provided the RFC in question to show where and why it was defined that way. He pretty much dismissed me by saying "MUD's don't use TELNET, they have their own *standard*".
First time I read this, I thought this viewpoint was a bit extreme. But strictly speaking, he is more right than wrong. Telnet and MUDs are not joint at the hip, and the vast majority of MUD servers do fine with a small fraction of "Telnet-like" behaviors. Having a proper Telnet implementation (or even any Telnet implementation at all) is not a prerequisite. You could choose to support only negotiations for the more popular protocols that clients use, or even no negotiations at all, and your server will still be playable on the vast majority of them. In the case of LFCR, it's the server developer's prerogative to decide that he/she doesn't care to support clients that don't accept it just because it's not "proper" TELNET. I'm not sure how many clients that would disqualify, but I have a feeling it would not be many.
Technically, as long as your game server can talk to at least one client, you have a working scenario. This is the case for the vast majority of games out there and no-one except MUD devs is working extra hard to ensure that their game is playable on now-museum-worthy terminals.
I remember quix saying in an old thread here in response to a question I had,
Quote
This may be a shock to you, but the vast majority of MUD's out there do NOT support TELNET. Many of them just read data from the TCP socket that connects and assume it's all game data. A few will use a subset of TELNET to negotiate specific things, like NAWS or TTYPE. Very few actually have a proper TELNET state machine to really speak the protocol correctly and handle whatever a TELNET client might choose to send.
So yeah, I also have a realistic view :). On the other hand I think doing things correctly enables a better client experience.
I pointed out that he was sending DikuMUD style backwards line endings (LFCR), rather than following the TELNET standard of CRLF, and provided the RFC in question to show where and why it was defined that way. He pretty much dismissed me by saying "MUD's don't use TELNET, they have their own *standard*".
First time I read this, I thought this viewpoint was a bit extreme. But strictly speaking, he is more right than wrong. Telnet and MUDs are not joint at the hip, and the vast majority of MUD servers do fine with a small fraction of "Telnet-like" behaviors. Having a proper Telnet implementation (or even any Telnet implementation at all) is not a prerequisite. You could choose to support only negotiations for the more popular protocols that clients use, or even no negotiations at all, and your server will still be playable on the vast majority of them. In the case of LFCR, it's the server developer's prerogative to decide that he/she doesn't care to support clients that don't accept it just because it's not "proper" TELNET. I'm not sure how many clients that would disqualify, but I have a feeling it would not be many.
Technically, as long as your game server can talk to at least one client, you have a working scenario. This is the case for the vast majority of games out there and no-one except MUD devs is working extra hard to ensure that their game is playable on now-museum-worthy terminals.
It's not that they won't work… it's that they won't work right. The reason I pointed it out is that changing the incorrect LFCR to the correct CRLF is stupidly simple…. one big search and replace, and then a handful of cases where the pattern didn't match. It took me half an hour to do on my old DikuMUD, once I realized it was doing it wrong.
As an example of what this does to clients… tinyfugue does NOT support TELNET negotiations, however it *does* assume that line endings are following the TELNET standard. The place it shows up, if you're backwards, is in trigger matching. Let's say you want to define some triggers to color (or act upon) damage messages from the game. Maybe the game prints "A fireball SLAMS into you for 43242 damage!". So, you define a trigger to match on /^A fireball/.
The problem is, if the client is expecting CRLF, and you're sending LFCR, That first LF gets treated as the end of the line, and now the line doesn't start with "A fireball", it starts with "<LF>A fireball", which does NOT match the trigger.
So… yeah. Do I expect everyone to take the time and effort to make a whole TELNET stack that works properly? No. Do I think it's reasonable to make a pretty trivial change that will fix known issues and not hurt ANYONE? Yes.
21 Apr, 2014, bozimmerman wrote in the 9th comment:
Votes: 0
RE: supported telnet options.
It's in a weird place, so not too shocking it was hard to find. Check here, around line 890 – there's a list of supported telnet options in CoffeeMud, the only java mud for which I can speak. :)
@plamzi, Coffee does implement msp, mxp, MSDP and GMCP, i3 and imc2 (see https://github.com/bozimmerman/CoffeeMud... ). I'm not sure about other general telnet telopts. However some of these implementations seem closely bound to Coffee-specific game logic and assumptions.
No doubt Coffee will be a valuable reference though; I also forgot to add groovymud to the references,
I've noticed you're making a lot of commits on CoffeeMUD lately at GH, is it a general cleanup or are you adding stuff too?
edit: I should say, I've looked at CM more since I started this thread, and I've been more and more impressed by it. But honestly the thought of stripping it down to the gameplay I want scares me a little.
I tried to write some primitive telnet support into my own code, but I find the RFCs to be a little unclear at times and sometimes lacking in clarity. What I have simply checks bytes as they come in, if it hits an IAC it expects it to be the starting byte of a three byte sequence and thus waits for the remaining bytes, processes that and then goes back to normal input handling (which is to say it essentially captures strings and buffers them). It's really not much good for anything than one shot options where you ask something to be turned on or off as it doesn't support sub-negotiations in any way. I can never decide whether the code should be in the client (which makes a sort of logical sense) or in the server (which might be useful given that the server is the part that wants to know and the client, at some level, simply doesn't care since it just passes one more bytes in either direction (or ought to just do that).
There really is something unfortunate about having to write your own net code, especially the telnet bits (if you want that), just so you can write your own -working- mud server. It's interesting stuff to know, but it's a nuisance when you just want to do something like a combat system or an interactive menu or have color. And, of course, you'd rather have your own code that you sort of understand rather than someone else's which you don't understand.
^ I think it's kind of sad that games can't avail themselves of the special powers of a true terminal application with keypresses and psuedo graphical interfaces, but that's a whole other kettle of fish.
—
I think you should implement as many protocols as you can, as long as they have modestly clear specifications or find a way to make it easy to write code for a new protocol. That way your work has the most applicability possible.
05 Jun, 2014, bozimmerman wrote in the 12th comment:
Votes: 0
Hi Idealiad,
While I am always (trying hard to be) on top of problems and bug reports, new stuff tends to come in spurts. Lately it's been expanding random areas sample data, and on the tech/space engine, which is very very slowly taking shape. There should be a new build in a week or so, as I've become comfortable with the stability of the stuff added last month. As for cleanup, yea, that happens from time to time too.
As for your own mud-dreams: be bold. The whole reason for open-source is to do what you suggest – take some crap someone else wrote and make it your own without starting from scratch.
I've noticed you're making a lot of commits on CoffeeMUD lately at GH, is it a general cleanup or are you adding stuff too?
edit: I should say, I've looked at CM more since I started this thread, and I've been more and more impressed by it. But honestly the thought of stripping it down to the gameplay I want scares me a little.
I'm going to use it for my own game, but also try to make it modular enough that someone can adapt it for their own use. It may not be just plug and play, but since a lot of the work I'll be doing involves pulling out the useful telnet stuff from other codebases, I'm hoping this lib will make it easier on anyone else down the road.
These are the resources I'm using:
http://www.advogato.org/person/elanthis/...
http://cryosphere.net/mud-protocol.html
http://commons.apache.org/proper/commons...
https://bitbucket.org/tvernum/terebi/src...
https://code.google.com/p/miniboa/source...
http://www.mudbytes.net/file-2825
https://github.com/seanmiddleditch/libte...
https://github.com/Twisol/anachronism
http://tintin.sourceforge.net/mssp/
http://tintin.sourceforge.net/msdp/
http://tintin.sourceforge.net/mccp/
Tips and advice are welcome.