Patch 22 broke Easy Color, and possibly other color code

From: Tseran (
Date: 10/17/02

Now before you say that I am nuts, try taking a stock bpl22, apply Easy
Color (which isn't easy with the changes) and then look at a room which
you add a lot of color codes to....with colors turned off!  This is why
it doesn't work:

In the new process_output, it takes the output buffer, sends it, counts
the number of characters it sent, removes that many characters from the
output buffer, and then checks if it has more to send.  If it does, it
sends that and so on.  Now imagine two scenarios with the same data:
200 characters of text, 50 of that is color codes (2 characters each),
including the last 2 characters of text to send.

1. With color on, any color code is generally replaced with 5 or more
characters.  Since this was done inside the process_output, that 200
characters is not 275 characters when it is sent.  It sends it and then
tries to remove 275 characters from the output buffer.  Is there
anything to stop it from removing more then there is?

2.  With color off, all the color codes are replaced with nothing, so
those 200 characters are reduced to 150 and sent.  The MUD sends the
150, and then says "hey, there's still 50 in the buffer!" and sends
those 50 into the process_output, which may or may not be stripped more
and send, leaving less than 50, and sending.  It will eventually wear
itself down to the last 2 characters, a color code, which it tries to
send, sends 0 characters as the code is stripped, removes 0 characters,
tries to send again, sends get the idea.  I put a log() in
proc_color from the easy color, that's how I noticed it.

Now, as I see it, we have 2 choices: process color BEFORE it hits
process_output, but that may take several lines of calling, since there
are more than one way to add text to the buffer.  Or.  We can try to
chance process_output a little bit so that it can handle these
Now with PGP Encryption!  Ask for your public key TODAY!

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT