Zugg Software :: View topic - [1.33] Bug with ANSI and #SUB or am I daft?

Posted: Fri Jun 01, 2007 8:36 am

Problem with #SUB and ANSI triggers...

Ok this one is a little complicated, and I admit up front it may be that I have some ANSI characters floating around wreaking havoc.

Consider the following ANSI Regex

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

The escape chars did not all show up but, if you copy and paste them they are still there. Strange!

Anyway, this calls back to an older bug or two about trying to capture and replace multiple things in the same trigger. Or even color multiple things.

That said, this is a new permutation of it. I was able to crash cmud with this one. So it is a bug, if not an unexpected one.

Try parsing the text in the script of the trigger using the whole line and substituting it that way. Sorry.

Posted: Fri Jun 01, 2007 3:26 pm

Well that's the next step but I also wanted to do partial lines.

The idea is to use MXP to give you a clickable link to buy the item if you meet the level and money requirements, and just show the money value as a digit (if you don't meet the level). Now I've got this working perfectly as just a plain text trigger, but since I lose color information, version 2 would convert the ANSI color to MXP/HTML colors and resub.

I was trying the partial line since I thought that would be easier to do. I can try capturing the entire line, and doing the partial replace manually then subbing the entire line. I'll if that works and post later.

Posted: Fri Jun 01, 2007 6:16 pm

I responded to this in the feedback email, but I think the problem is that the #REGEX command currently has a problem with the /nnn syntax for control characters. This is on the bug list.

Oh, I should also mention that I'm not sure how well (or not) the #SUB command works with the #REGEX command. I've only tested #SUB (and #PSUB, #PCOL, etc) when using normal CMUD triggers. I'd be interested in knowing if a similar normal CMUD trigger has the same problem.

Also, you might have trouble when using #SUB with ANSI triggers. Remember that the ANSI codes are not being captured directly from the MUD...they are reproduced based upon the screen output to let you trigger on them. But you can't "substitute" them to get rid of them or anything like that. So it's possible the inclusion of the ANSI codes in the trigger text is screwing up the character count used to perform the text substitution.

Posted: Fri Jun 01, 2007 6:40 pm

Since the whole regex only contains one colour code, couldn't you use the line colour option to avoid those character-counting errors, if that's the problem?

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Fang
Nope, the line contains several colors before you reach the part he wishes to trigger on. Also the regex is set to accept any ansi color.

Zugg
Yes, the behavior is the same on both regex and regular triggers.
There is more going on here though. That substitution actually matches TWO parts of his trigger line.

This is the double match and double substitute that he is attempting.

Posted: Sat Jun 02, 2007 5:17 pm

It looks like normal #SUB triggers work fine with matching multiple items (at least with my testing). So I think the problem is with the ANSI control codes. When you use an ANSI trigger, CMUD computes the ANSI color codes and inserts them into the string being tested. When using #SUB (or #CW) where it checks for multiple matches in a line, CMUD cycles through the line looking for all matches and then performs the proper action on each one (substitute or color). When substituting multiple items, it's a bit tricky to keep track of the current position in the string (since the string is being modified), and my guess is that the hidden ANSI color codes are causing the index and count to get messed up.

Anyway, I think this just effects ANSI triggers, but if you find another multiple substitute trigger that fails, let me know. But I've put this on the bug list.

Posted: Sun Jun 03, 2007 11:53 pm

Just an update on this I've mostly got this working by subbing the whole lines and separately only processing the part that I want. The odd thing is that I'm seeing some strange behavior with the carriage return being eaten, it's probably related. Right now if I had 1 carriage return it's gets eaten, but if I add two I get double line spacing.

I'll try to see if I can't GAG the line.

Posted: Mon Jun 04, 2007 12:03 am

I couldn't gag the blank line but it occured to me that I could just avoid using #SUB. I'm processing the entire line now gag the old line (i.e. the one received from the MUD) and call the new line with #MXP.

Now to clean up the code and work on getting it into the package library.