Zugg Software :: View topic

Beginner Joined: 16 Sep 2008 Posts: 20

Hello. I'm using CMUD 2.37, and having an issue with ansi code behavior at line ends. It seems that wherever the window sizing dictates a line end, CMUD automatically inserts an ansi end code, the %e[0m with a new on one the next line. This makes it difficult to catch entire paragraphs of unknown length, and pull it apart by color.

Is there a way to have CMUD go strictly off the ansi codes sent by the MUD rather then injecting it's own? If not, about my only option that I can think of is to catch each line individually, strip the code, and append them to each other to get the entirety.

Wizard Joined: 22 Mar 2007 Posts: 2320

Are these linebreaks being inserted by your mud, or by Cmud? If by the mud, have you checked whether you can turn off word-wrapping from the mud?

Can you describe what you are trying to do a little more clearly? It sounds liike you want to trigger or capture lines of a particular color. There shouldn't be any difficulty with that, so I'm not sure I understand what you want to do.

Beginner Joined: 16 Sep 2008 Posts: 20

Yes, sorry if I was unclear, a bit more detail, I guess.

I have a paragraph consisting of an unknown number of lines, 2-4 different colors. I'd like to pull out the first color, just the first color but don't know how many lines it will cover. The mud has word wrapping off, and I had hoped by doing so I would only have to worry about making a trigger between the initial %e[x and the final %e[0. The problem is Cmud seems to be inserting and extra ansi end/begin code at it's perceived line breaks. I know it's Cmud doing it because if I adjust the window sizing to move a few words between lines, the location of the ansi end/begin code moves with it.

Beginner Joined: 16 Sep 2008 Posts: 20

The main reason I was going to go this route was it doesn't seem to like MXP, was going to it manually. After playing around, the ANSI thing seems to be related to my MXP woes. For example, if I show the MXP commands, I see <RDesc> and </RDesc> where they should be. On a new room create, if I open up the room's description on the map, it has extra line breaks where Cmud's word wrap separates.

In both the ANSI and MXP cases, if I turn off word wrap in the options, the problems go away. Of course, it makes it impossible to read. In both cases, Cmud seems to be adding in code at the word wrap breaks, causing problems.

Wizard Joined: 22 Mar 2007 Posts: 2320

I'm still not sure what you mean by "pull out the first color". Say you have a paragraph which changes color, red, then blue, then green--do you mean you want to capture and do something with only the red part? Is the part you are worried about always the same color, or do you really mean whatever color happens to be first?

If it is always the same color, the first method I can think of would be to write a regex trigger which ends at an escape value other than 0 or the color you want. Make it optional, so that if will also match the end of the paragraph.

Beginner Joined: 16 Sep 2008 Posts: 20

It is always the first color, and it is always the same color, yes, it would only be the red part in your example. I see what you're saying, rather then end the trigger at the %e[0 have it end at anything but that or the initial color code, which would cause it to end when the next color kicks up.

That might work, I'll have to play with it. On a side note, any idea about the MXP stuff, or different question, different post? Ideally if I can fix that, would render the ansi stuff moot, but as far as I can tell both are caused by Cmud inserting end/begin code at the arbitrary word wrap points, rather then only at mud-provided. Is there a way to turn off this behavior? I'd rather fix the cause then the symptoms, if at all possible. It prevents headaches in the future.

Posted: Fri Apr 23, 2010 6:17 pm

Yep, it is CMUD that is inserting that to reset the color at the end of the line. Because of how CMUD tries to recreate the ANSI codes for color triggers, it ends up with the %e[0m in the text. This is already on the bug list along with some related issues. I will need to rewrite how CMUD handles this entire operation so that CMUD can really return the *actual* ANSI codes received from the MUD rather than trying to recreate them. But this isn't going to get changed before the next public release, sorry.

Beginner Joined: 16 Sep 2008 Posts: 20

Ah, no worries on the fix, at least I know I'm not crazy or dumb. I can do workarounds until then, I imagine. Thank you for your time.

Any ideas about the MXP doing what seems to be the same thing? Is that included in the same related issues, or is that something else entirely, that I might have a chance at fixing?