It seems that colour codes shown on the screen are ignored if they are at the beginning of the line
My guess is this is the result of r1083. They still show in the console fine, but using:
]/bind \ "echo ^1foo"
when \ is pressed with the console closed foo appears in white.
Created attachment 1782[details]
store two colour codes in Item_Text_Wrap
Thanks Amanieu for finding the function containing the bug.
I still don't quite understand the workings of said function, so I'm not too confident about this patch, but I can't reproduce the bug with it applied.
Created attachment 1801[details]
Patch based on svn 1094
A few bugs in the existing implementation, fixed with this patch (not benmachine's):
- First color code is not taken into account because 'p' only starts after the first set of color codes have been stripped.
- Color is reset after 2 lines because of the Com_Memset that resets 'c'
- Second color string check loop will never be used
Created attachment 1782 [details] store two colour codes in Item_Text_Wrap Thanks Amanieu for finding the function containing the bug. I still don't quite understand the workings of said function, so I'm not too confident about this patch, but I can't reproduce the bug with it applied.Created attachment 1801 [details] Patch based on svn 1094 A few bugs in the existing implementation, fixed with this patch (not benmachine's): - First color code is not taken into account because 'p' only starts after the first set of color codes have been stripped. - Color is reset after 2 lines because of the Com_Memset that resets 'c' - Second color string check loop will never be usedCreated attachment 1802 [details] Patch based on svn 1094 Don't propagate color codes when there is a manual newline.Created attachment 1803 [details] Patch based on svn 1094 Make initial color ^7 instead of nothing, prevents overflows.