DescriptionChris "Lakitu7" Schwarz
2008-11-28 03:54:42 EST
/echo prints each token seperately, so in a string like /echo ^1test 1 2 3, the subsequent tokens (1 2 3) will not be colored.
While this is incredibly trivial, the credit for actually noticing it and fixing it goes to Amanieu.
Comment 1Chris "Lakitu7" Schwarz
2008-11-28 03:55:58 EST
Technically the color code should still propagate even if the printfs are separate. The actual problem is that the client console doesn't propagate color codes properly.
That's questionable. Not propagating colour codes across prints sounds sensible to me - frequently the prints are unconnected, and in such a case I can't imagine you'd ever want the colours to continue to the next line. Allowing the codes to propagate would also require adding a whole lot of ^7s, and if there are any non-terminated colour prints in the original q3 gamecode there is no sensible way to deal with them.
The intended behaviour is to propagate colors until a \n, and that's when it's reset to white. This bug was unnoticed for a long time because whole lines are printed most of the time.
Comment 5Chris "Lakitu7" Schwarz
2008-12-10 20:09:47 EST
I agree with Ben. It's really just not very practical to expect the color codes to propagate across disparate printf calls. It's very practical to expect calls to printf in hard-coded situations to include (possibly redundant) color codes. The problem here is with /echo, not printf.
Created attachment 1933 [details] easy fix