Zugg Software :: View topic

Posted: Tue Mar 29, 2011 1:58 am

#CAPADD WindowName
#WINADD Windowname $paramter

Appends the line or selected text to the last line in a given child window, similar to #SAYADD, put preserving color where applicable.

Wanderer Joined: 02 Sep 2005 Posts: 85

well, somewhat related, but new function idea (even though it's been suggested before? kinda)
%roomborder(vnum, color) -- colors room borders.. i dunno the status of this one, though..

Posted: Tue Mar 29, 2011 4:27 pm

Shalimar: Have you tried doing:

Posted: Tue Mar 29, 2011 6:20 pm

Yea, i wans thinking how i could redirect the #sayadd over there
but there is no way to capture and append to a current line and retain the MUD color codes.

Maybe a better method would be a means of shifting the prompt to be at the end of the last line
Then a standard capture would do what I want

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Tue Mar 29, 2011 10:39 pm

Yes, but #SAYADD uses the default window color

:window:#SAYADD %line

this will not retain the colors used in the line when sent from the mud, which rather defeats my purpose

i could add it in myself it remained static, but this trigger picks up three differently colored channels

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Not quite. #SAYADD uses whatever's in the variable being referenced, and in the case of %line it's been internally %stripansi()'d. If you create an ansi trigger and #SAYADD %1, you will find that whatever's in %1 will be colorized.

Posted: Wed Mar 30, 2011 2:34 am

yes, but like i said, my trigger fires on three different colored channel windows, so to test what you said i would have to separate them out so i could bind it to a single ansi color

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Umm, what? I totally didn't understand what you were trying to say here. Ansi triggers are not limited to singular colors, nor do you need to limit yourself to literal ansi-code text like in ZMud. Similarly, if any particular ansi codes are unimportant for your purposes you don't even need to explicitly match for them in the pattern unless not doing so interferes with matching any non-ansi-code stuff you're trying to reach.

Besides, for testing purposes, just create a new contrived trigger to play with that you can then simply delete after you've learned and explored the concept troubling you.

Posted: Wed Mar 30, 2011 8:08 am

If it makes you feel better, I don't exactly understand your suggested workaround either.
I thought you meant the old method of preserving ansi be checking the ansi box before pasting in the copied text from the scrollback buffer.

Currently, the code I am using (with some help from this thread) to simulate a #CAPADD command is as follows:

Wanderer Joined: 21 Aug 2008 Posts: 85

[edit][/edit]

Apprentice Joined: 22 Mar 2009 Posts: 149

Try replacing the line :OOC:#SAYADD %1 with :OOC:#SAYADD %concat(%linecol, %1) It's a very simple solution that just uses the variable %linecol to maintain the first color used in the line. I'm not sure if it'll work, and it won't maintain more than the first color being used, but if that's sufficient to your needs, it's worth a try.

Using an ansi trigger will work for more than just the first color being used, but it would also mean a more complicated pattern for state 1 of your trigger, and some parsing to maintain the colors while eliminating all of the unwanted white space that your trigger pattern is removing.

Posted: Wed Mar 30, 2011 3:55 pm

Once i turn on ansi (on the #COND), it stops capturing the additional lines of text
Doesn't seem to do anything if its only selected on the main pattern.

Apparently %linecol is expanding to -1 instead of some ansi codes, so that idea doesnt work either (it is also completely undocumented in the help files)

Any other ides to better simulate #CAPADD?

Apprentice Joined: 22 Mar 2009 Posts: 149

%linecol is listed under 'predefined variables'

Could you post a few examples of the lines your mud is sending you that you want this trigger to match, complete the the ansi codes? The easiest way to do that is probably to open up the debug window (type #DEBUG) and make sure everything under 'Options' is disabled while under 'Messages' only 'Show raw session input/output' is enabled. Then copy/paste us a few of the valid examples.

Posted: Wed Mar 30, 2011 6:07 pm

Ah yes, I see it now.

Single line example:

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

In your case, Shalimar, you simply need to include a subpattern to match color codes in general rather than specific ones (unless it's possible and likely you're going to get spoofed and you need to literally match based on color.) Wildcards work fine, so something like (%e[[%d;]m) will capture the color for you to use at the point of display.

Just include that in the state 0 trigger, and then change your #SAYADD to #SAYADD %t1%1

Posted: Thu Mar 31, 2011 12:31 pm

Apprentice Joined: 22 Mar 2009 Posts: 149

Try:

Posted: Thu Mar 31, 2011 5:05 pm

that does not capture additional lines at all

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Fri Apr 01, 2011 2:58 pm

1. I agree, but the text is still there to be matched weather it is seen in the end display or not..
2. Sorry, been editing this so much, forgot to recheck that option. On fixing that it still isn't retaining the color codes for me.
3. If the above check box is the only difference between my code and yours, then why isn't it working for me?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

1)uh, no it's not. In a non-ansi trigger, the trigger parser uses the same value assigned to %line (no ansi codes at all). In an ansi trigger, it uses the original line (with ansi codes). Since the first thing in the pattern is the subpattern for an ansi code, state 0 without the ansi trigger option checked should never fire at all (which means that if anything from state 1 was happening your trigger was stuck on state 1 at the time you initiated the test rather than starting from state 0).

3)only two things I can think of: 1)corruption is interfering with your result like it did in my first test (albeit, it looks like %t1's new value is still unprintable) or 2)some other trigger is executing first and producing an uncolored version of the same line (your trigger would then operate on this result instead of the no-longer-existing original line sent from the game).

Apprentice Joined: 22 Mar 2009 Posts: 149

I consistently get an access violation error when I try to combine %t1 with the focus syntax :<window>: or <window>: so a different error from the one you experienced, Matt, but more evidence to suggest its a bug. %t1 seems to work fine for other uses, but not when it's being combined with the focus character : This was on an otherwise empty Cmud session.

A workaround to that issue that worked for me in testing it was to change the line :OOC:#SAYADD %t1%1 to #EXEC {:OOC:#SAYADD {%t1%1}} so that the variables are expanded before the command or focus syntax get parsed.