ansi colors

I realize that this isn't exactly MC related, but I thought I'd draw on the talent here. Two things I'm confused over w/ANSI.

1. How long do codes take effect? Do they apply only to the packet/line, or to any following text as well?

2. Is it likely to find any codes with more than two numbers, ie \e[#;#;#;#m ? Also, what exactly is the definition of 0, 1, and 2 here? I've many different answers by googling this, but I'm still confused. The standards apparently aren't very standard.

They certainly apply to more than the packet, I would say they apply until cancelled or changed.

You might have more than 2, eg. bold, underline, foreground colour, background colour.


0 is supposed to be "reset", which I think means "go back to standard colours, cancel bold etc." although I'm not sure of the exact definition. There is an RFC on it I think.

1 is bold although I think it really means use the bold (highlight) colour set rather than a bold font.

2 - I don't have a definition for here.

Yes. Bold in the case of Ansi is more accurately 'bright'. There was no such thing is a 'bold' font back when they came up with it, which makes the behaviour of using a bold font when a bold ansi command arrives incorrect. Some like underline and italic where I think added later for some special applications, but usually required a custom display, since there was no single device at the time that supported all of them. Even when PCs came along with graphics cards, they didn't support some of the codes, though they could have if the developers had bothered to add such support directly into the hardware. But bold and italics would have both required changing the number of pixels used to show the characters, which would not have worked in any but a pure graphical context, which text modes didn't use.

Hmm ok, thanks. So you have to roll through all remembered codes to get the current color eh? Another question if you dont mind :)

Suppose you didn't want a client to display ansi. Is it more traditional to evaluate the colors and remember them but simply not display the text in the appropriate color, or simply forget evaluating while ansi is off, so that if ansi is put back on, text that was received while ansi was off, appears colorless?

Another question, when is it appropriate to use normal connection sockets, and when is it appropriate to use UDP connectionless sockets? Does this depend on the server at all?

Thanks for all the help guys!

Yes, text recieved when ansi is not being processed is in the default [0;37m color, which is the normal grey color, like you see in a DOS window, unless someone changes the clients color settings that is.

I assume that by 'normal' you mean TCP/IP.

TCP/IP sockets are guaranteed lossless, so everything you send *will* be received and in order of sending unless the connection goes wrong. This is guaranteed by a constant ping-pong between the server and the client; if the server does not receive confirmation then it resends until it's happy. TCP/IP will stop sending packets if it stops getting confirmation.

UDP is more like "just send the darn thing" and hope that it gets there. UDP guarantees nothing except that it throws a packet onto the network with an address tag.

Most 3d or otherwise network-intensive games use UDP because you can't afford to stop sending packets. They come up with clever embedded repair systems to compensate for potential packet loss and custom acknowledgment systems. In general, UDP packet loss isn't that bad, so this tends to work.

On a MUD, the number of packets sent is so small, and you absolutely need to get the packets in order (imagine getting your room description split up almost randomly!), so unless you reimplement TCP/IP in UDP (a somewhat foolish thing to do), you might as well use TCP/IP.

I agree with Ksilyan on this. You would use UDP for situations where you can afford the odd loss or out-of-sequence situation.

One that springs to mind would be a thermometer connected to an internal network that monitors the temperature (or rainfall etc.). The occasional loss of a reading would not be a big problem.

Also, with UDP you can "broadcast" packets onto the subnet, so in the example of the temperature-measuring, it could broadcast the temperature, and every PC on the subnet could read it, without having a packet per PC.

Oh yes, I'd forgotten about broadcasting, which is indeed one of the very important features about UDP.

BTW Nick will be replying to your 'city builders' message ASAP. :)