I spoke with a friend and he gave me this idea.

Website <---> tcp/ip protocol <--> telnet to tcp/ip server <--> twgs

Basicly, create a second server that communicates to users in the tcp/ip protocol and communicates to the twigs server in telnet.

What this would do is to allow modernized web techniques for clients to connect to the tradewars game. Clients could be built directly into web pages.

You would also have much more control over all kinds of game reports directly drawn into a web page format.

Anyone got thoughts on this concept? Im gonna make this server. I will consider it like a modern day "translator" for telnet and tcp/ip .

Well, I think there are a few well known ways to tackle TW on the web, but I don't know if these are the kinds of things you're talking about. First is a standard Java or Flash telnet client. Second, a Java or Flash helper. In the second case, I think you could do just about anything any other helper does. There have been a few projects like that.

Those are all good ideas

My main goal is to remove the need for a telnet client completely. I envision a website itself to be the entire client.

You go to the website and you play the game. Everything on the page interactive.....

There are java telnet clients out there, there's at least one open source one. Of course getting it to support modern helper operations will probably never happen, since there's just no money in it. But if you want to crack open one of those clients and make it a helper, feel free.

Aside from the fact that I should probably be doing something like this myself, I don't really know why it hasn't been done more by the community. There are sites that provide Java and flash telnet access to their games. I don't know that just providing a text-based web interface is enough to matter, because those who actually care enough to run this game probably know about telnet or helpers, or they're being initiated by someone who does.

I think if/when it becomes possible to represent the game in a more graphical manner, then it might be time to create a web interface to the game. This is why I'm wanting to explore a flat map option, because I think that's key. If the game map can be shown visually, and you can interact with the game through a map rather than just a vague cluster of sectors without any obvious connection to other sectors, then we might see more graphical interfaces to the game cropping up, and it seems likely some of these would be flash or java. If I create one myself, it would likely use the Torque-to-web engine which I've used for other games. That's a powerful engine that can put an FPS into a browser, so it's more than capable of providing a dynamic, graphical TradeWars client.

Both of you have good points.

Its hard to decide where to take it.

I am going to experiment with this translating server. I will update later when i can visually see what I believe might be kewl.

I am also working on the jta library also. I was telling a friend about the jta library when he gave me a new idea using a translation server.

I will develop the translation server in C#
I will develop the new jta concept in java

I'm not sure I understand the need for a translation server. What function would it serve? Couldn't a web-based client include logic to parse TW output directly?

At no time am I saying anything negative about twgs. Everything I am talking about is, in my oppinion to make it better.

First lets look at how apache web server works
Browser <--> tcp/ip protocol <--> webserver

Current twgs
I could be wrong about the twgs clients but ... as far as I know...
Purchased client <--> telnet protocol <--> twgs server.

My desired version

Web Browser <---> tcp/ip <--> twgs server.

No purchased client needed. The basic idea of playing a text based game manually is not attractive to anyone. Everyone wants a client. Now how many new players want to fork up money to buy a client to a game that they may not want to play long term?

Telnet is an ancient protocol. The average programmer who works with modern languages work more with the current web based languages.

Can a web page designer build a telnet client? I doubt it. Could a web page designer build web pages if the data was made available by tcp/ip. I bet!

The idea would enable lower level programmers, like those who have a little knowledge of javascript, html, xml, php, sql, etc to build useful accessories for twgs that would help to build a better player base.

Currently, I believe that there is a "monopoly" on the client issue due to the telnet protocol. How many more developers would the game system have if it were easier to communicate with the server? Using the normal web based languages?

I always have a hard time explaining what I am envisioning. For sure, if i am able to complete what I desire, I will be able to show everyone exactly what I am trying to achieve.

All has to better the game, I am a big fan of twgs and mean no disrespect to twgs or anyone associated with twgs. Twgs rock!

I think you overestimate the involvement of the telnet protocol in the process. TWGS uses the telnet protocol only in a basic way. It sends a set of telnet configuration commands to tell it what it expects. That's it. After that, it's raw TCP/IP. RLogin is a bit different, so TWGS negotiates the RLogin connection to pull in the login name that's transferred during connect, but after that, again, it's raw TCP/IP. All you're getting from TWGS during gameplay is raw text output. It includes text and ANSI sequences. That's it.

The thing to realize is that Telnet is a protocol that is carried over TCP/IP. So is FTP. TW doesn't really use a true protocol, because a protocol assumes that the client parses the commands being sent. Telnet just displays the raw output. If there's a protocol here, it's ANSI, because telnet is processing those ANSI codes to move the cursor around and set colors, and maybe that's what you're talking about translating. If that's the case, I see the point of that. I've considered having a layer between TW and the client that could translate the output to various formats.

I wouldn't worry too much about the telnet protocol. I never did ;)

The main problem I see here is that telnet maintains a constant connection between the client whereas HTTP/HTTPS does not. Although HTTP/HTTPS can maintain a "session", it can't be used as the sole method of comunication with TWGS.

There are two aproaces you can take:

1. The web server can provade a Java, Flash, or Silverlight application to the user. Instead of text this client would provide a GUI and handle comunication directly with TWGS. You could start with an existing web based telnet client, and add graphical attributes.

2. You could write a web application that provides the GUI. This would be difficult, because you need some method of maintaining a constant connection with the TWGS.

I thought about using Silverlight in the project I am working on, but all data/Maps/etc would have to be stored on the server side, so I went with WPF instead. I dislike Java and Flash, so I don't know much about their capabilities.

Another thing you have to consider, if you want to completly get rid of the text console is that Tradewars sends a lot of Out of Bound Text (OOB). Messages like fedspace communications, and player/alien entered you sector. Anything that you request, i.e. when you send "P" you expect to get a port prompt or an errror that there isn't a port in this sector. OOB text isn't requested, which makes it difficult to handle.

Right, you need to maintain a constant TCP session between the host and client. That basically means you need something that speaks enough telnet and handles enough ANSI, while staying connected to the server, to play the game. That's why I suggested the java telnet client, since it's fairly close to what you need. A flash client would be fine too, or maybe an HTML 5.0 client would work too.

I noticed that when i connected to the socket if i sent it an IAC DO SUPPRESS_GO_AHEAD

I do get a menu but it doesnt appear to negotiate like i expected... I see your point on what u just said...

So does that mean that once i begin recieving the data, i just need to process the ansi coding and text?

Yeah. You won't receive any additional telnet codes from TWGS after startup.

That makes things a whole lot easier for other people who want to develop add ons for twgs....

I hope you havent minded all this... i assumed a few things never realized....

BBS suport for telnet varies a lot. I have putty set to 48 lines, and I have noticed some BBSs will re-size it to 24 lines. This is one of the features of telnet that is supported by putty and that particular BBS.

Since you are not dealling with a BBS, none of those features are needed.