Zugg Software :: View topic

Posted: Fri May 02, 2008 3:59 pm

Pictures speak a thousand words:

The top two lines are what is shown in MUD output. The timestamp is there only because I did a history, but it still shows those colors and whatnot. The bottom two lines are in my captures window. Seems that color is getting lost in odd places...

Charneus

Edited with a new picture and new description.

Posted: Fri May 02, 2008 4:18 pm

Next time, try saving it as a gif. jpegs are horrible for anything except photos, especially things like text, where you need clean lines.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

It might help to post the trigger(s) you're using to capture these, too.

Posted: Fri May 02, 2008 4:48 pm

There is only one trigger capturing this line, and this is what it is:

#TRIGGER {^~(Friend~)} {#CAP captures}

By the way, that isn't me (Aron). It's one of my friends on my flist. It's weird, however, that the first LETTER is captured correctly, but everything else isn't. I'll try to get a better picture up there. Don't know why I saved it as jpg. Probably something I forgot to reset. Heh.

Charneus

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Sat May 03, 2008 4:30 pm

Posted: Sat May 03, 2008 6:52 pm

When did this turn into a "this makes for better pictures" thread? Heh. Anyway, does anyone have any suggestions to what's happening? Again, I'm assuming it's with the ansi change. As a side note, the colors are not sent MXP. They are sent via Aardwolf color commands. That is, they type:

@RThis is a red sentence.

It comes out as:

This is a red sentence.

Sigh.

Charneus

Posted: Sat May 03, 2008 7:14 pm

Nope no suggestions as to what is happening. I guess it's time to do some debug files and send them to Zugg.

Posted: Sat May 03, 2008 7:44 pm

Debug logs would probably help, so we can try and reproduce what's being sent. I'm not seeing anything weird trying to simulate it using #say. It could perhaps be because you have your styles set up differently in the different windows (I'm guessing that's why the fonts are different) so check that, too.

Posted: Sat May 03, 2008 8:22 pm

I'll have to do the debug logs either tomorrow or Monday, then. Yes, I do have different styles in both windows, but it did work without this problem in 2.22. However, I'll change them to be the same as soon as I can. By the way, not sure if you can actually simulate it using say. However, if you want to try, the colors are red, bold red, cyan, bold cyan.

Charneus

Posted: Mon May 05, 2008 5:19 pm

I'm afraid that I need to see the raw data from the MUD that is creating the initial text display. Run the Script Debugger and make sure the Raw Input/Output message is enabled. Then copy/paste the raw data being sent from the MUD within [code] tags in this forum post.

I *did* make some changes to the routine that captures the color data from the screen (the same routine is used to capture the data sent to log files for HTML logging). And there was a bug regarding some ANSI sequences that might be effecting this.

Posted: Mon May 05, 2008 6:46 pm

Hope this helps. This is what was in the script debugger:

Posted: Mon May 05, 2008 7:13 pm

That isn't the correct data from the script debugger. I need you to turn on the Raw Input/Output message and copy/paste that raw data from the debugger window. The data that you pasted is the ANSI output message, which is the data generated internally by CMUD when to copy/paste a line.

What the data you pasted is showing is that CMUD is adding the ESC[0S sequence, which tells CMUD to display the text using the default color for that window. So maybe the default colors for the two windows are different?

But without seeing the raw data sent from the MUD, I can't determine why CMUD is adding the ESC[0S sequence. The data from the MUD will never have ESC[0S in it, since that is an internal ANSI code added by CMUD itself to support styles.

Posted: Mon May 05, 2008 7:39 pm

Then perhaps something is wrong with the script debugger. I do have Raw Input/Output selected, as indicated by this screenshot:

EDIT: Removed image due to possible offensive material. Didn't notice it before! :P

Unless there's something else I need to do, too.

Charneus

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

#DEBUGFILE?

Posted: Mon May 05, 2008 9:00 pm

Right. It's the "i" lines that I need for your example. You could turn off the "h" option for ANSI codes to avoid getting the wrong data displayed in the file.

To understand this better, the "i" Raw lines are the actual data sent from the MUD. The "h" ANSI lines are the result of CMUD trying to recreate the ANSI codes by looking at the line on the screen. The #DEBUGFILE writes the "i" raw lines to the disk file.

In any case, post the "i" lines from the Script Debugger for the example that has the wrong color.

Wizard Joined: 17 Jun 2006 Posts: 1201

Err what the heck kind of Mud is that?

Posted: Mon May 05, 2008 10:31 pm

Yeah, charneus probably needs to edit his example images a bit in case someone might be offended. But honestly, it doesn't look all that different from the common chat channel in World of Warcraft these days. Kids.

Posted: Tue May 06, 2008 6:34 am

Posted: Tue May 06, 2008 11:44 am

That's interesting - I thought a new line was CRLF, not LFCR? Does it make a difference?

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

LF/CR is non-standard, but didn't Zugg say he changed CMUD to handle them?

Posted: Tue May 06, 2008 6:15 pm

CMUD (and zMUD) will properly handle these old MUDs that use LF/CR. Yes, someday it would be nice if the MUD coders would update their code to actually follow the telnet standard. I've ranted about this before. Even though this violates the telnet standard, CMUD handles it, and I don't think it makes any difference in this case.

The problem is that the routine to capture the color/mxp of a line was changed to fix some bugs. When I decided to implement the HTML logging feature, I thought it would be easy because I already had an option to capture the MXP of a line (from the MXP Capture option that was added a few versions ago).

But I didn't know is that the MXP capture actually had a lot of bugs that hadn't been reported. Guess very few people used it. So when I was fixing these bugs for the HTML logging, they caused some side effects and new bugs that is effecting the normal ANSI capture. In this case, it is adding the ESC[0S style codes where it shouldn't.

I am hopeful that I can get this fixed today.

Posted: Tue May 06, 2008 9:14 pm

Fixed for 2.24