Zugg Software :: View topic - [2.37] HTML logging broken? Still buggy in [3.09]

Wanderer Joined: 29 Jan 2008 Posts: 63

When I try to save buffer to a long only ansi colors are converted to correct tags.
Other colors are replaced with 
I wonder if I'm doing something wrong

Example:

Posted: Mon Nov 10, 2008 5:37 pm

Does this happen when using normal logging, or only when using the Save Buffer command after the fact?

Wanderer Joined: 29 Jan 2008 Posts: 63

Happens when using normal logging too.

Posted: Tue Nov 11, 2008 5:45 pm

Confirmed and added to bug list. Seems the problem is actually with the #COLOR, #CW or #SUB commands. If the MUD itself sends you text with that color, then it gets logged correctly.

Posted: Thu Feb 05, 2009 10:21 pm

Fixed for v3.04. This was the same bug as the other #CW bug that I fixed today. It was effecting color logging as well.

Wanderer Joined: 29 Jan 2008 Posts: 63

[3.05] still buggy.

When text from a mud comes with ansi color codes and I try to replace it with different (non-standard) color using #PCOL, it is not saved correctly to a html log.

How to reproduce:

Trigger:

Posted: Fri Mar 13, 2009 6:56 pm

I'll add this back to the bug list. Not sure why it works with #CW and not #PCOL.

Wanderer Joined: 29 Jan 2008 Posts: 63

There is some mess with how ansi and non-ansi colors interact together. Some of them come from a mud and some are brought by triggers.

More experiments:

Triggers:

Posted: Fri Apr 17, 2009 8:17 pm

When I tried to reproduce this again to fix it, I couldn't get it to fail. I've already fixed some other color problems a couple weeks ago, so maybe this bug was related to them. Let me know if it still doesn't work in v3.06.

Wanderer Joined: 29 Jan 2008 Posts: 63

Still buggy in 3.06.

It looks like in 3.06 PCOL isn't always closed correctly. On a screen it's ok but in a log PCOL-colored pattern isn't closed until the end of the line. It happens when I try to recolor some text that already has ansi colors coming from a mud

For triggers above I get this log:

Wanderer Joined: 29 Jan 2008 Posts: 63

More experiments.
It looks like there is some mess when original mud output has ansi colors.
And I have a wild guess (probably false) that there is some specific additional miss with red ansi color "31m"

Triggers (trimmed)

Posted: Mon Apr 20, 2009 5:02 pm

I'll put this back on the bug list to take another look at it. I agree that the problem seems to happen when mixing #PCOL using MXP colors on lines that already have ANSI color.

Wanderer Joined: 29 Jan 2008 Posts: 63

One more problem:
This is not exactly logging issue but rather a run-time issue (which probably cause logging issues as well).

Trigger:
It may look a bit wierd but its purpose is to split an incoming line with a prompt and an arbitrary text into two lines: the prompt and the the text, also preserving original colors.

Wizard Joined: 22 Mar 2007 Posts: 2320

This code displays just fine here from the command line:

Wanderer Joined: 29 Jan 2008 Posts: 63

I'm saying that the trigger output is not what I expect to see.
The "show" command is just supposed to fire the trigger and it works (I guess).
This issue is run-time but the problem is very closely related to what happens with HTML logging.

Wizard Joined: 22 Mar 2007 Posts: 2320

Your formatting is incorrect. Change this:

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Wed Apr 29, 2009 7:58 pm

Rahab is correct about this. CMUD wants the { at the end of the line that starts with the } and not on it's own separate line. It's possible the parser might handle it, but it might be something that will break in the future as it is not officially supported syntax. You can use the Reformat command in the Editor menu to tell CMUD to format your script properly.

More importantly, I'm guessing your script has some hidden ESC control codes embedded in it, which are not being displayed on the forum. You should always try to avoid embedded control characters. You can use the %e variable in CMUD for the ESC character. Also, using the [0S option to try and force the default style isn't something you should be messing with. The internal style implementation is using non-standard ansi codes and could change in the future. The proper way to reset the ANSI color back to the default is with:

#PRINT %ansi(reset)

Enchanter Joined: 09 Sep 2007 Posts: 605

Wanderer Joined: 29 Jan 2008 Posts: 63

Thanks for hints.
I used [0S to remove the default PRINT color. I wonder if we have more clever way to do that for PRINT/SAY (instead of using %ansi(reset) or ESC codes).
Can we update #IF syntax (and other statements syntax) in the documentation? I don't remember seeing brackets restrictions and it works fine for me so far when I put them on separate lines (I guess I just got lucky).

My script has no additinal ESC codes expect that one before #PRINT (and in the trigger's pattern). By the way, what is a correct way to put ESC codes in patterns?
I made these syntax changes but the problem is still there (not affected at all).

Updated trigger:

Wanderer Joined: 29 Jan 2008 Posts: 63

One more addition.
This problem seems only exists for simple ANSI ESC codes. I can't reproduce it for bold codes.

What I mean (mud text is taken from the script debugger):

<<ESC>[31m16%<ESC>[0mhp 100%m 99%mv>
This one displayed with unclosed red color after my trigger fires
g test |-> Line 1247 gagged
a test |
a test ]<16%hp 100%m 99%mv>
h test ]<<ESC>[31m16%hp 100%m 99%mv> <ESC>[0m

<<ESC>[33;1m27%<ESC>[0mhp 100%m 100%mv>
This one is displayed fine. The only difference I see here is "longer" ESC sequence for yellow color.
g test |-> Line 1265 gagged
a test |
a test ]<27%hp 100%m 100%mv>
h test ]<<ESC>[1;33m27%<ESC>[0mhp 100%m 100%mv> <ESC>[0m

PS. And the original problem with HTML logging seems depends (but is wider) on how CMUD internally reformats incoming ANSI colored text. Even if I see it correctly on my screen, a HTML log is still broken.
It looks like this
<10hp 1 1> 
you fled! 
<10hp 1 1> 
you fled! 
for both colors, red and yellow

Wizard Joined: 22 Mar 2007 Posts: 2320

Using %ansi IS the clever way to change the default color of #print.
You must have been lucky. I have seen #if statements work incorrectly a number of times if the fail statement is placed on a completely separate line. I don't see any reason to change the #if documentation--there is nothing in there to suggest that you can put it on a separate line.
Replace the embedded escape codes with %e. The reason the embedded escape code doesn't work well in the #show is that it is not expected to work. Don't use embedded escape codes. The mud output will get interpreted correctly. It is the zscript code that should not have embedded escape codes, because that can mess up the scripts. You still have embedded escape codes in the trigger pattern.

Both of your examples seem to work fine for me here, once I properly replace those escape codes with %e.

Wanderer Joined: 29 Jan 2008 Posts: 63

I tried to replace ESC with %e in my trigger, but while my trigger works for #SHOW command (that uses %ansi) it doesn't work for real mud output or #SHOW with ESC char. That's my original problem. #SHOW doesn't let me to reproduce the problem if I don't put ESC codes into it. I would really appreciate any hint how to mimic the real mud output, so I could reproduce things offline.
Another question, how I can mimic real mud output that is supposed to fire prompt triggers (triggers that has "prompt" option and supposed to fire on the end of a block, not the end of a line)

One more question. Can you look at HTML log? For me even if I don't see any problem on my screen, my HTML log is still screwed.

PS. Considering #IF syntax. When I reformat scripts with ctrl+M, CMUD puts else-statement on a separate line in many cases. This may be misleading, so it's always good to have syntax description in the documentation.

Wizard Joined: 22 Mar 2007 Posts: 2320

An %e in your #show command gets replaced by cmud with the escape character as it processes it, so it is exactly as if the mud sent the escape character. Embedding an actual escape character in #show or a script can mess things up, so any testing using that is worthless. It's not expected to work.

To see what your mud is actually sending, you can try this: in your session window, highlight the mud prompt you want to check out. Hit ctrl-c to copy it. In your package editor, create a new blank trigger. Mark the Ansi Trigger checkbox. Then click in the trigger pattern and ctrl-v to paste the prompt text. You will notice that cmud replaces the escape character with %e when pasting to the ansi trigger pattern. To use that same text in a #show, you may have to massage it a bit, by quoting some of the special characters with a tilde ~.

To simulate a prompt line from the mud, use the #sendprompt command.

This is the first time you've said this is different on your main screen and in the HTML log. When you started talking about it, you said it was not an HTML logging problem. I'll see if I can get a problem to show up in HTML logging.

Wanderer Joined: 29 Jan 2008 Posts: 63

The whole thread is about HTML loggin problem.
With 3.06 fixes the nature of HTML logging bugs has changed.
In 3.06 the main problem I see is unclosed colors. It can be reproduced without any ESC chars in triggers, several posts above you can see examples with coloring triggers (~17-19 Apr)
However, in 3.06 in some rare case the very similar problem (unclosed color) started to happen run-time (on my screen, not only in a log). My guess that these problems are related somehow, so it probably makes sense to fix them together.

So far fixing syntax didn't help with any of these problems. While I certainly welcome any hints how to write this or that thing in a clever way, there are issues I can't fix by syntax changes.
This particular run-time problem with the trigger above and unclosed color happens to me when I'm online and to reproduce it offline I have to use ESC in #SHOW. If I change #SHOW to use "right" approach and %e or %ansi codes this will just disable the possibility for me to reproduce my problem offline, but it does not help to actually fix the problem.

I don't get the idea of #sendprompt. It sends a prompt TO the mud, but how I can mimic a prompt FROM the mud to fire my prompt triggers offline? By the way, the "prompt" trigger in this thread is not a real trigger prompt. It's just an ordinaly end-of-line trigger that is supposed to split a prompt and a text when they come from a mud together.