Generally when you grab a string of data from a line, you don't get the carriage return and/or linefeed. You just get the line up to the CR/LF and then decide how you want to use it. If you echo it to a terminal, you'll write it with a CR/LF, but if you just use it to populate fields in your app or whatever, you won't.

Something to keep in mind also is that TW and TWGS has some pretty funky line termination characters, and for legacy reasons they haven't been cleaned up. You may get CR/LF, you may get LF/CR, and the most common end-of-line for the game itself is actually CR followed by an ANSI reset sequence followed by LF. And don't be surprised if you find anything else odd going on in there.

Right. But if you're using something like Java's BufferedReader.readLine() to read text from the game, it'll hang on prompts because they're not terminated. You have to use a character-based read instead of a line-based read if you want to recognize prompts before the player sends a response.

Yeah, definitely.

I hear ya on that. I have seen some funny business. *joke* .

Using C# Socket Class. In simple terms.

1. Check for data in the recieve buffer of the socket. Saves alot of time not to read data unless there is something to read.
2. Read out the data from the recieve buffer. (this can be any and all data that the server has sent. No matter what the input.
3. Store data into a buffer for manipulation and compulation.
(haha. I always wanted to use those words.)
Note: the socket recieve buffer is completely different than the buffer you store the data. I am not even sure if you can access the socket class buffer.
So I am not reading one buffer to store into another just for fun. Its so I have a readable buffer of my own.
4. Perform whatever I want prior to display.
5. Display.
Now currently,
i have the main thread. A sender thread. and a reciever thread.
Maybe even more threads not sure.
The recieving of data, the sending of data, and the user interface all operate independantly of each other.

I am reading the buffer in 8 byte characters. I convert to string as needed. Or leave as byte - depends on what I am doing

Note: I am reading 8 byte information from the buffer converted to the 1252 video display ( which is the iso-8859-1 display ). I have the ability to read the most important bit which is a 1 for a telnet command and a 0 for data. Also note this is not needed due to the way the server is operating

As far as I can tell the server is sending data and I am getting a "\n\r" at the end of every line. Here is an example of what I get so far:

All the wierd characters when read as bytes are numbers (telnet negotiation stuff - like 255 IAC) . Every line ends with a "\n\r" except the last line which is a prompt. And I am sure I wont be surprised at what else I see

Another update. Been away. Got side tracked on my xbox game. I decided to release my xbox game as a Windows Version Freeware. Rock Blocks is the name of it. Currently I have completely converted it to play on windows machines. It will require an xbox controller, but that should not be a big deal for gamers. Xbox controllers work well with windows. I added a highscore posting system that allows the game to post high scores online so all players on the internet can compete against each other. Anyway...

Just an update. I will begin to work on the twgs client as soon as I finish the website for Rockblocks...

Hope all has been going well in the forums. Ill have to check what everyone has been up too