Zugg Software :: View topic

Apprentice Joined: 18 Feb 2007 Posts: 190

in zmud i used, example:
#TR {^\<tagname\>(.*)$} {#SUB {"%1"%cr};do some stuff} "" regex|color

now this trigger would capture any line beginning with <tagname>, and store ansi codes in substring, hence #sub would replace line with part after tag in original colour

in cmud this pattern dosnt match with ansi on and without it i have no way of recovering the colour codes

Apprentice Joined: 18 Feb 2007 Posts: 190

figured workaround for this one out using reparse... still, i dont see why shouldnt it work like it did in zmud

Posted: Thu Oct 09, 2008 9:47 am

Firstly, because CMUD parses out MXP tags it doesn't recognise by default now. You can turn this option off, so that only registered tags (those that CMUD has a built-in behaviour for and those with defined MXP triggers) with the "Show unknown tags" option in the MXP preferences. Or you could set this up as an MXP trigger.

Secondly, the syntax "%1" no longer does what you're after because "" is now used to delimit literal strings. Nothing inside a "" is parsed. You can do what you're after by simply removing the quotes, though.

Finally, I think it'd be more reliable if you didn't use the ANSI option at all and instead used the <color> tag or the %ansi function to change the colour to whatever you want, rather than using the probably-undefined behaviour where you're subbing in a string from an ANSI trigger and relying on CMUD to choose the right colour for you.

Apprentice Joined: 18 Feb 2007 Posts: 190

indeed, however
my cmud syntax had stripped quotes, i got around it (the rest) after reading one of your old posts (thanks! :))
now its
#TR {^\<tagname\>(.*)$} {#SUB ""} "" regex
#COND {(.*)$} {do stuf} regex|reparse

however, im getting to converting my minimap engine and im worried again about ansi capture thing
-unexpectedly, it worked very nicely

Apprentice Joined: 18 Feb 2007 Posts: 190

frankly, i got pretty fed of this, zmud programming was quirky, but once you knew how _exactly_ it works there was very little that couldnt be done in couple lines of code in one trigger...
ansi capture issue has nothing to do with mxp tags, im getting same thing on aardwolf
#TR {^{chan ch=(\w+)}(.*)$} {redirect %2 according to %1 here} "" regex|color wont even fire, wo ansi it fires but obviously dosnt capture coloring of %2
so with cmud not only id had to have multiple ch=xxx triggers, but each of them had to be multistate, and so long easy configuration (of many things, including captures) with one variable being RECORD of LISTS

anyhow, while cmud offers couple nice features, namely telnet triggers, #switch, loop breaks, threading, speed and some gui improvement everything else goes against ease and flexibility of programming, forcing use of zilion of triggers, trillion of variables and extensively long code, forfeiting gains from precompilled zscript code, not to mention overhaul of new candy features of dubious usefulness, like package library, xml, scintilla, inability to script in notepad, etc. those would be acceptable if functionality was still there.

until functionality of script engine is back - back to zmud for me

Posted: Sun Oct 12, 2008 1:39 pm

You still haven't explained exactly what you want the first trigger to do. As I understand it, you just want to change the line's colour to the default color. That'll be easier in future versions when you can choose a style for a particular line manually, but now it should still be as easy as #sub <color whatever>%1</color>. This seems pretty elementary to me, so I'm guessing there's some intricacy of your problem that you've not explained that's forcing you to use the ANSI trigger.

Secondly, I'm not sure what you're trying to do with the second trigger. The way to move things to other windows while preserving their colour is the #cap command, though - were you using that?

Also, showing us some example lines so we can check your pattern - and possibly fix it so it matches the line properly - would help.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Apprentice Joined: 18 Feb 2007 Posts: 190

fang, #cap works fine mate, however i wanna add timestamp at beginning of the line AND preserve original colour, exact code from zmud for aard

#TR ID_CHANNEL {^{chan ch=(\w+)}(.*)$} {
#IF %ismember("%1",@config.capture) {#WIN chat %ansi(3)%time(hh:nn)%ansi(7) "%2";#GAG} {
#IF %ismember("%1",@config.gag) {#GAG} {#SUB {"%2"%cr}}}
} "" regex|color|case|notrig

and yes, "%1" stuff, turned to %1 for cmud nodnod, i checked in debugger, same trigger wont fire with ansi on and fires ansi off, this is issue of ansi trigger

viji, try matching it when part (.*) changes colour, ansi triggers dont match at all this configuration, nb. line starts with default colour, aard does that a lot with its tags

but this is only one straw, biggest problem is cmuds lack of support for lists in records, i was expecting to pop and push to those in cmud, but instead i cant even addi/deli

test line:
#SA "{chan ch=gtell}(Group) mychar: 'aaa'"
ansi trigg wont match it, even wo any colour anywhere

nb. also tried variations with \e[0m at beginning/end

nb2/edit:
also, i tried to fire it with #ec and #sh as well
as simple experiment with
#TR {^a(.*)$} {#SA %1} "" regex|color
seems to be working only with #sh (fe. #SH aa%ansi(3)aa)

Posted: Sun Oct 12, 2008 4:00 pm

Click the capture window so it's selected, click Prefs on the toolbar, session on the side, scrollback on the top, check Show Timestamps and put in whatever format you like. Job done.

This new timestamps option was added for exactly this reason - it takes far too much effort to add them otherwise.

Apprentice Joined: 18 Feb 2007 Posts: 190

i want timestamps in various colours and specific format, sometimes some messages wo timestamp, sorry mate, simplicity != for average joe
iow, i want ansi triggers to capture colour codes, vor various purposes, just like zmud, is it too much to ask!?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I made some changes to your trigger.

The reason the pattern wasn't matching for you was because of a leading ansi code. Your original pattern had "^{chan" and would not match when the actual line started as "←[34m{chan". The change in the pattern allows a leading ansi code.

The next change was just a little bit of restructuring for speed, and eliminating the addition of the time stamping in the #WINDOW command. CMud provides built in time stamp display for all windows. If you open the Preferences for a window you will find the time stamp controls under Session on the Scrollback tab.

Here is the modified trigger

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Hrm, were are all posting at the same time. I tested the #SAY from your edit and it works perfectly with the pattern I specified.

I have to disagree about the matter of simplicity; it is for the average Joe, John, Dick, and Jane. You are expressing that you want a complex set of results, and that moves you out of the range of avarage.

Apprentice Joined: 18 Feb 2007 Posts: 190

i see, this one actually makes sense, ansi triggers solved, thanks vij

Apprentice Joined: 18 Feb 2007 Posts: 190

never had this problem in zmud when line began with default colour, so it never occurred to me to try hence the ansi issue...

now if zugg will be kind enough to fix lists in records, mebe even with pop for them, disable records autosorting, and mebe add pop/push records to record var... ?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The reason CMud needs the addition to the pattern is because it added the concept of styles. These are not really completely utilized yet; but the idea is that the mud might indicate some text to be in a specific style, and the user would be able to define the details of that style. At this point it is still in the planning stages, however the new internal style codes are at a level where ANSI triggers can detect them. This again is part of looking ahead to where a user might want to trigger when a specific style is applied to the text.

As far as I know, the main hold up in fully implementing styles is that Zugg doesn't want to unilaterally add to the MXP specification. That specification was devlopped through a cooperative effort by a number of client developpers and mud admins. While your speficic issue doesn't use MXP, the full development of styles would. Hopefully Zugg will be able to bring this addition into a completed state in the near future.

Your issues with nesting lists within a record variable belong in a seperate topic, and I seem to recall you have one started already for that. We should continue discussions about that issue there.