Zugg Software :: View topic

Posted: Sat Apr 23, 2005 5:44 pm

I have
#REGEX {^@liste2 destroyed (.*)\.$} {specific unimportant stuff;common stuff}
#REGEX {^@liste2 completely devastated (.*) with awesome force\.$} {specific unimportant stuff;common stuff}
and 15 or so other similiar triggers in a class. Trigger on trigger disabled to skip parsing if it matches one of these.
So far so good.
I've decided to consolidate them in one, better readability, but more importantly to flag lines that doesnt match any of that.
%regex has no option for case sensitive that I could find. Ah well, guess will have to live with that.
trigger pattern ^(*)$
#VAR t2 0
#IF (@liste!="") {
#ALIAS abortcmd {}
#IF (%regex( %1, "^<@liste2> destroyed (.*)\.$", t)) {
stuff specific to this match
#VAR t2 1
#ALIAS abortcmd {#ABORT}
}
abortcmd
#IF (%regex( %1, "^<@liste2> completely devastated (.*) with awesome force\.$", t)) {
stuff specific to this match
#VAR t2 1
#ALIAS abortcmd {#ABORT}
}
abortcmd
and those 15 others in similiar fashion here.
}
#IF (@t2=1) {common stuff}

And here we have t2 flag showing match as well as matching line in %1.
trigger on trigger gets emulated #abort-ing out of #IF on first match. Might or might not be better for performance, hard to say.
I run the trigger with a 10-15 lines and it CHOKES the system. cpu shoots up to 99% used by zmud. Granted my cpu is ye olde kranky pentium 3 450 but come on, text processing, it never goes above 30% under lots and lots of triggers, 40-50% in most extreme conditions.

I poked around a bit, first thing tried I swapped ^(*)$ for ^*$ and using %line instead of %1, not much effect, then I removed anything and everything leaving skeleton.
#IF (%regex( %1, "^<@liste2> destroyed (.*)\.$", t)) {}
#IF (%regex( %1, "^<@liste2> completely devastated (.*) with awesome force\.$", t)) {}
and those 15 others.
very minor improvement, 88-95% cpu used with 10-15 lines fed in at once.
Tried on 7.04 and 7.05, guys what am I doing wrong here, must be something retarded, couldnt be such difference between #REGEX and %regex?
Oh yeah, title mentions %match. using %match or %regex has no effect on performance just like it doesnt seem to matter for triggers.

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

You are doing nothing too wrong, you should switch back and split them to two separate triggers.
You see Zmud has a bug when you give it to much to do at one time and it will start to mess up and skip and a bunch of other things.
Zugg is aware of this problem and since a small amount of us ever run into tis problem it will be sometime before it gets fixed. So be patient I have been waiting 2 years so I could run a script I wrote to work. When the bug is fixed I will have a wonderful script to post for everyone.

Posted: Mon Apr 25, 2005 3:05 pm

Zugg is aware of this? cool.
it doesnt mess up and skip things, it chokes the living daylight out of CPU.
Later tried on a mighty 2.8Ghz CPU it choked it to 99% utilized as well.
Heres to hopes next zmud version #REGEX {^pattern$} {} about same CPU time as #TR {^(*)$} {#IF(%regex(%1,"^pattern$")) {}}
And case sensitive %regex please Very Happy

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

the problem is that the trig and regex works but when you have alot of stuff on one line going into the trig that it needs to do and then triggers on itself
or
if you have a line that has more than about 6 triggers on
mine is a #sub that gets hit about 6 to 10 times a line and you should see that slow down a cpu and skip.

sometimes there are work arounds though.
what you need to do is catch all of what you wand and store it into a database variable
then loop thourgh it one line at a time, giving zmud a breath inbetween lines.
use #alarm for that

I could give an example, but I don't have time right now I need to get back to work, heheheheh.

Posted: Mon Apr 25, 2005 10:19 pm

So the %regex idea bombed. On to plan B. I'll do it with separate "no trigger on trigger" triggers and stick a * trigger at the end which fires if nothing else gets matched, a like so
#TRIGGER {^{@liste2} destroyed (*).$} {#VAR liste4 %additem( destroy, @liste4);#ADDITEM liste5 {%1};#SUB @liste4" ("@liste5")";#VAR mobhits 1} "mobhits" {notrig}
and then
#TRIGGER {^(*)$} {#VAR mobhits 0;#VAR liste4 "";#VAR liste5 "";#PSUB "%1 - moo" %x1 // testing, delete me} "mobhits" {notrig}
Not only do I have {notrig} option, but also help file for sub states,
"Substituted strings are not processed by further triggers."
Apparently zmud has a second opinion on it though,
#VAR liste2 moo
#ECHO moo destroyed Elf.
output
destroy (Elf) - moo
and mobhits var gets set to 0, without a fail. Now what am I doing wrong?

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

what exactly are you tring to do start at the beginning.

Posted: Tue Apr 26, 2005 2:36 am

What I want is so simple its embarassing I havent done it myself yet, a hit parser that briefs hits and condenses consecutive hits in one line.
One way or another I want to flag when a line doesnt match any of hits messages, there are about 17 or so.
As shown below hit message gets briefed #SUB @liste4" ("@liste5")"
then if the previous line was also a hit line, it gets cut #IF (@mobhits=1) {#GAG -1}
incoming
moo destroyed Elf.
moo completely devastated Other Elf with awesome force.
different moo completely devastated Elf with awesome force.
output
destroy|devastate|devastate (Elf|Other Elf)
If possible, I wouldnt want to get databases involved for such simple thing.
Since going through every line with ^(*)$ bombed, over 100 active triggers is fine, barely any lag even on old CPU, but put a few string compares in one trigger and splat, then I can think of only two things.
One is that trigger on trigger thing. If all 17 hit message triggers are flagged no trigger on trigger, then a * trigger should fire when a line doesnt match any of those triggers. doesnt work that way, no idea why.
The other thing is to make a trigger that says do not match any of these strings.. well what can I say, today I looked at regex syntax for NOT matching something and wept. Something about positive lookahead and conditional pattern,
(?(?=^(the_only_string_you_dont_want_to_match)$)^$|.*)
more than my little brain can handle.

Posted: Tue Apr 26, 2005 5:02 am

Posted: Tue Apr 26, 2005 5:23 am

At any time I have about 100-200 active triggers in zmud on a mediocre computer, and it never stutters 30% CPU usage peaks, plenty of wildcards and all. Yet 17 %regex compares bogs CPU down to 99% used. From what I understand, #TR and #REGEX gets passed through optimization before handed over to regex library, while %match and %regex are handed direct. Man, must be some wicked optimization then. Would it be hard to implement that %match and %regex also gets the nifty optimize treatment? Very Happy

Posted: Tue Apr 26, 2005 6:15 am

As I said, the %match and %regex directly call the Perl PCRE library. I have no control over what that library does. There is no way for me to further optimize them since they are functions that work with normal strings, and not necessarily just triggers, and there is no way to know in advance what string you will call these functions with.

Triggers can be optimized because zMUD knows that you are going to test the same line from the MUD over and over again. That's just the way it is I'm afraid.

Regular expressions weren't added for speed. They were added for people who absolutely needed some of the advanced functionality that they can provide. For 90%+ of your triggers, you can just use normal zMUD triggers which are faster.

As someone mentioned, if you post what you are trying to accomplish, perhaps one of the Gurus can offer more suggestions on how to do things more quickly. Using a ^*$ kind of trigger and then calling %match and %regex should really be used as a last resort only since it bypasses all of the optimizations that zMUD can help with.

Posted: Tue Apr 26, 2005 7:00 am

Posted: Tue Apr 26, 2005 6:09 pm

Let me put it another way. When you use #TR or #REGEX, zMUD is using *COMPILED* code to loop through all of your triggers and test them against the current line from the MUD. When you use a trigger like ^*$ and then call the %regex or %match functions, you are running *INTERPRETED* zMUD scripting code on every line returned from the MUD. Of course this is going to be a LOT slower. It's like comparing compiled C code to interpreted VBScript code. It has nothing to do with the optimization of regular expressions. Sorry if I didn't focus on the main problem with your method...it was late last night when I replied.

zMUD scripting is slow. It's a string-based parsed language. Running a huge script on each line returned from the MUD is a sure way to completely hose zMUD and bring performance to a stop.

"Regex for dummies"?? That is what the normal zMUD trigger syntax was invented for from the beginning. It has most of the power of regular expressions, but with simpler syntax.

So first, try to give up using regular expressions for now. Unless you *really* know what you are doing, regular expressions will just give you trouble, expecially with doing something complicated with the (?:) syntax. Yes, it will give you a headache and won't work the way you think it does. Not my fault...I didn't invent how regular expressions work. I avoid them myself because they never do what I want and they give me a headache, just like you said.

If I were doing something like you described myself, the way I would probably do it is to create a trigger for each condition. Let it match the condition and set a variable when the trigger matches. Then to handle the "didn't match anything" condition, have a single trigger that fires AFTER all of the others with the ^*$ pattern and simply check the variable to see if it is set or not.

E.g.:

#TR {^%*$} {#VAR Matched 0}
#TR {^@liste2 destroyed (*)$} {#VAR Matched 1;other stuff here}
#TR {^@liste2 completely devastated (*) with awesome force$} {#VAR Matched 1;other stuff here}
...
#TR {^%*$} {#IF (@Matched = 0) {nothing matched, so do other stuff here}}

This way, you only have a very short script running on each line. All of the other triggers are optimized.

Posted: Tue Apr 26, 2005 8:37 pm

That was actually my second idea how to get it done.
With all due respect Zugg, you wrote the most rocking mud client, but the variable needs to be zero only if the line doesnt match hit messages. The triggers have to go in the other order. ^%*$ at the bottom as well as {notrig} for hit messages.
#TRIGGER {^{@liste2} destroyed (*).$} {#VAR liste4 %additem( destroy, @liste4);#ADDITEM liste5 {%1};#SUB @liste4" ("@liste5")";#VAR mobhits 1} "mobhits" {notrig}
#TRIGGER {^(*)$} {#VAR mobhits 0;#VAR liste4 "";#VAR liste5 "";#PSUB "%1 - moo" %x1 // testing, delete me} "mobhits"
Weirdest thing though, though, the no trigger on trigger part isnt working as I thought it should.
#VAR liste2 moo
#ECHO moo destroyed Elf.
output
destroy (Elf) - moo
and @mobhits is set to 0

Posted: Tue Apr 26, 2005 9:16 pm

Err, I think I picked the wrong wording. What I wanted to say is, that while your approach isnt completely wrong, it involves two ^%*$ triggers that fires on every line, while mine has one that only fires on lines that are not hit messages. What can i say, I have old CPU, I am gentle with it Very Happy

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

you guys are defiantly out of my league I stopped understanding back at regex.

I was simply referring to the issue of Zmud slowing down when you give it to much to do on one line. I had figured that was his problem and if he could find a way around it, then he would solve his problem. In the end he did just that and seems to be heading him in the right direction.

My problem comes when I use triggers to match multiple items in one line then try to rewrite them back to the mud using #sub.

It always messes up and slows to a grind, then in the end misses a lot of what I needed it to do.

But on reading your thoughts on #priority I will re-write it and see if that clears it up.

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

I tried it and it crashed again, well back to waiting for that bug to be fixed.

Adept Joined: 20 Jul 2004 Posts: 268

Posted: Thu Apr 28, 2005 9:00 pm

Status update. Tried a few things, including #TEMP which for whatever reasons reacts on {notrig} different on its creation line.
So far closest to working is emulating {notrig}, unfortunately double ^%*$ trigs couldnt be avoided after all.
#TRIGGER "mobhitsID2" {^%*$} {#PRI {#T+ mobhitsID}} "mobhits"
hit messages triggers here, now including {#PRI {#T- mobhitsID}}
#TRIGGER "mobhitsID" {^%*$} {#VAR mobhits 0;#VAR liste4 "";#VAR liste5 ""} "mobhits"
Testing with #ECHO-ing hit message simulations gives flawless performance while real muds output breaks off at a whim.
annihilate (Vesta)
devastate (Vesta)
pummel|0 (Vesta)
etc
Because offline testing works I suspect other triggers somehow interfering. I think I'll handle from here. Thanks everyone for replying :)