Zugg Software :: View topic

Posted: Sat Jan 08, 2005 1:48 am

I have been converting some of my capture triggers to ansi triggers. In doing so i have come across a couple of minor problems which don't occur with the counterpart non-ansi triggers.

1st problem

Mud ouput

(G) (W) Joe Bloggs is here.
A big scary monster is here being very scary!

Ansi trigger

#trigger {%e[33m~(G~)%e[1;37m~(W~) %e[1;36m(*)} {#sub maginery Char} "" {color}

Output

Imaginery CharA big scary monster is here being scary!

I've tried testing with different preference settings and trigger options. Also with changing the syntax of the trigger slightly but always with the same result.

The only work around i could find was to add a carriage return which gives you an added blank line.

I'd quite like to know the reason behind this for a better understanding of ansi triggers. More so than an actual solution which i would hope i can work out myself with a better understanding. A couple of threads touched on this but i still don't have a complete picture.

I'm aware its to do with what you receive from the mud and what gets sent to an interpreter before its made available to your scripts?

There is the same escape code on the end of each line sent by the mud but this can't be used in my triggers as it stops it from matching. Why?

Is that what im seeing with emulation control codes unchecked not exactly what is being sent? Or is it being stripped by zmud before it's made available to triggers etc?

2nd problem

#TRIGGER {^%e[1;33m(*) ~(%e[1;32m(*)%e[1;33m~) tells the CLAN~: ~'(*)~'} {
#gag
#sub {%ansi( yellow)~(CLAN~) %1:%ansi( bright, cyan) ~'%3~'}
#capture talk_info
} "" {color}

The original clan message is in yellow and im converting it to cyan.

If someone sends a message to clan that is very long, either over two lines or very nearly it would colour the end parts in yellow.

This only occured when using the %ansi function

NB - Since a reboot this problem no longer ocurrs. I havent changed anything but it seems to no longer do this. I spent hours trying to resolve this. Maybe the reboot cleaned up some erroneous error.

I've spent many hours searching through previous ansi trigger threads. My knowledge has greatly improved but its still quite blurry.
This was the overall impression i got from the past threads in general.

I don't know about anyone else but the more time i spend looking at threads the more i go off on tangents when i read something new and interesting.

Reason i want to use ansi triggers

All this testing is working towards using the ansi codes to help me distinguish between mobs and characters. I'm aiming to do a zone walk adding mobs to a database and want to filter out chars.

I'm using version 7.05 and XP with latest hotfix(s)

Posted: Sun Jan 09, 2005 8:43 am

For the first problem, I think the #sub command predictably substitutes away a line feed. I simply place a %cr at the end of the substitution. I do not presume to know what actually goes on. My guess is that ANSI triggers are given a line containing control codes which include a form of line delimiter which acts as a line feed. When the #sub command works on a trigger text that reaches the end of the line, this delimiter is left out in the substitution. I can't complain, it gives me more freedom on whether or not to produce a new line.

For the second problem, I believe that when the #sub command is used in ANSI triggers, the substitution is simply pasted over the line. Picture the #sub command as a #psub command, except that by itself it determines where the line without ANSI control codes is supposed to begin and end, when dealing with the version of the line with ANSI control codes. If this is true, it can be seen that in certain cases the #sub can get it wrong.

ANSI trigger used:

#TRIGGER {%e[32mONE TWO THREE} {#sub {%ansi(bright,red)1 2 3}} "" {case|color}

Test command:

#show {%ansi(green)ONE TWO THREE FOUR FIVE SIX SEVEN}

Without substitution:

ONE TWO THREE FOUR FIVE SIX SEVEN

With substitution:

1 2 3

FIVE SIX SEVEN

FOUR went missing.

Neutral

Posted: Sun Jan 09, 2005 12:11 pm

Thanks Pega, nice explaination.