Alright.
I have my custom made logviewer, which loads a specefic log file into a @window, nothing special. Im using /loadbuf -p @window file.

However, if I use this for example:


It echos "hello" in red, "hey" in green and "test" in red.

But in the log file it looks like this:

(The long messy stuff after the first color is my timestamp)
This will echo my timestamp like normal, but "hello" is in white, "hey" in green and "test" in white aswell. Is there a way to make the logging work with the colors just like mirc does?

Im not sure if this should be a bug report or a feature request, however, feel free to move it if needed.

What are your logging settings? How your timestamp in your logging settings look like? I never had such problem before though.

well considering how the log file is read in a text editor, ud have to make the text editor read the chars like mirc does(thus enabling the colors)

Are you getting dumber?

ROFLMAO

Here's my logging settings: http://i34.tinypic.com/24fwm4w.jpg

lol @ Collective.

@Lindrian. I believe its your timestamp settings in anyway.

There are two obstacles in getting what you want to work. The second is the lack of support in /loadbuf for setting the line color based on the color in each log line (this could also be added as part of the -z switch to /filter). That would be a very valid feature suggestion.

For that, though, another obstacle needs to be fixed first, and I believe that this can in fact be considered a bug: namely, that the line color storage in the log file is ambiguous. As the helpfile states, the line color is only stored if it differs from the original color. This means that:

and:


are stored exactly the same way in the log file, namely as "<ctrl+k>04hi", even though they are different with respect to subsequent ctrl+o's or single ctrl+k's as your example shows.

As a result, there is currently no way to reliably decide for a line in a log file, whether this log line includes a line color or not. Even when it is known that "Line colors" was turned on in the options at the time of logging.

This could be fixed by altering mIRC's logging mechanism, to always include the line color prefix, i.e. even if the line color is actually the default color, if the first character on the line is a ctrl+k. That would remove the ambiguity during log parsing.

For now, you're basically out of luck. There just isn't enough information in the logfile to do this right, so there are no workarounds either. For your specific case you could make a workaround (involving /filter -k and seeing if a line starts with two color codes), but it would be slow and only work with your logs with the colored timestamps..

I see, thanks for the reply. Hopefully khaled will see this and 'fix' it. a -z switch for the /loadbuf would be perfect!

darn, was hoping for a response by someone on the "team", to tell if its a bug or not, and if there'll be a 'fix' for it.

As I said earlier, a -z switch similar to /filter would be really really good!

I believe Sat pointed out that ths problem here is not due to a bug, just a limitation of how log files work, maybe a design flaw, depending on your point of view. So really, there's nothing to fix, just more features to add. It's important to point out, though, that /filter -z is not the "feature to add", here, so your request isn't going to happen until mIRC's logging mechanism undergoes the improvement Sat described above.

If you were to make "on text" do something like this:

echo $color(text) $chan (CTRL+K) $+ $color(text) < $+ $nick $+ > $1-

wouldnt it work?

What? I didn't quite understand...

If you understood what Sat said, why don't you understand what The_JD said? That is making sure there is always a color code.

'cause it's supposed to be a log viewer, not a logging script itself, I assume...