Zugg Software :: View topic

Posted: Sun May 04, 2008 3:27 am

This frequently #RAISE'd event seems to cause alot of lag where typed text would not even show for several seconds.

#EVENT onKilled {
$killed=%1
$numkilled=%eval(1+@myKills.$killed)
#ADDKEY myKills {$killed=$numKilled}
}

@mykills has over 1000 entries

Posted: Sun May 04, 2008 3:32 am

Is @myKills.$killed compiling properly? Seems like it should be @{myKills.$killed}. Also, if it has that many entries, perhaps you should look into using Dharkael's excellent Sqlite script to make a real database?

Posted: Sun May 04, 2008 4:01 am

No errors on the compiled tab, so i assume it is.

I didn't think i would end up with this many entries when i started the script.
Or that such a simple thing would require a full database, are the lookups so much faster?

Posted: Sun May 04, 2008 4:07 am

Just sneaking in here for a quick peek. I'm not going to answer most of the posts until Monday, but I saw an obvious problem here that I wanted to help with.

Whenever you use %eval (or #EXEC), you are forcing CMUD to delay the execution until runtime. The expression within %eval is not compiled...it is treated as a string value and then compiled and executed each time it is run. This will make your script very slow.

Whenever you think about using %eval or #EXEC (or variations), always ask yourself if it is absolutely necessary. The proper way to write this script is simply this:

Posted: Sun May 04, 2008 4:59 am

i am still getting bogged down by this even with your code
it is especially noticable when i leave the settings editor open

if it matters i am running two instances of cmud and i also have a trigger as follows:

#TR {{@myskills}} {#CW saddlebrown}

i dont see the argument list you speak of though

Posted: Sun May 04, 2008 1:32 pm

It's a box labelled "Params" at the bottom, next to notes. The names of the variables go in there, separated by commas, $s optional but preferred.

Posted: Sun May 04, 2008 4:06 pm

This discussion prompted me to go through my code and eliminate the %eval uses throughout it. However, I wasn't able to get rid of the following:

$modified_health = (0.85*(%eval( %db( @settings_heal, health_sip)))) + %int( %if( @lost_bal( elixir), 300, -800))

Where: %db( @settings_heal, health_sip) = @max_health*0.78

Since the db variable contains a variable, unless I do an %eval it doesn't work. I have to leave %db( @settings_heal, health_sip) as a variable because the value @max_health can change at any time.

Posted: Sun May 04, 2008 5:00 pm

I was trying out various things, and this worked absolutely fine:

$modified_health = ((0.85*(%db(@settings_heal,"health_sip")))+%if(@lost_bal("elixir"),300,-800))

I've changed a few things (added brackets around the whole thing, put quotes around your strings, removed lots of extra spaces including the ones that were making you need %int for the return from the %if), so I'm not sure which change made the difference, but it works.

Posted: Mon May 05, 2008 1:16 am

Awesome, I'll have to give it another try. Thanks for the help.

Posted: Mon May 05, 2008 10:08 pm

I am still having the issue, about 10 seconds worth of lag each time the event fires, according to the timestamps.

As soon as i disable the event all the lag is gone.

Posted: Mon May 05, 2008 10:33 pm

So just doing:

#RAISE onKilled

will cause the lag? If so, can you send me a file containing your huge @myKills variable so that I can test this here? I tried creating a large database variable and couldn't get this to cause such a lag. Maybe my computer is fast, but I should at least be able to see some sort of time issue. Also show me exactly what your event contains right now.

I just can't see any way for this to take 10 seconds...that's a huge amount of time.

Can you also reproduce it if you put this event (and the variable) in a clean session all by itself?

Wizard Joined: 17 Jun 2006 Posts: 1201

Posted: Mon May 05, 2008 11:08 pm

My trigger thats calls the event is:

<trigger priority="100" id="10">
<pattern>(%w) {killed|dealt the death blow to}{ | the }(*).$</pattern>
<value>$killer=%1
$killed=%2
#CO red
#RAISE onLoot $killed
#IF ($killer="You") {#RAISE onKilled $killed}</value>
</trigger>

The event is:

<event event="onKilled" priority="150" id="15">
<value>$numkilled=(1+%db(@myKills,$killed))
#ADDKEY myKills $killed $numKilled</value>
<arglist>$killed</arglist>
</event>

Oldguy2: I dont think it has anything to do with it myself, i just threw it out as a 'just in case'

Looking into it with another session, it worked flawlessly, untill i added in the color trigger, then i got the 10 seconds of lag again.

So for goood or ill,
#TR {{@myskills}} {#CW saddlebrown}
looks to be the problem child.

Does it not like huge stringlists, or is it complaining cause i am using a database variables instead of a true stringlist?

Posted: Mon May 05, 2008 11:19 pm

Is the @myskills variable in the color trigger changing a lot? Each time it changes, that trigger needs to re-expand the database variable into a regular expression, which could take some time, but not 10 seconds.

A huge database variable or huge string list (either one) might cause a slow color trigger, because the regular expression parser has to deal with all of that text for each line received from the MUD. Vijilante might know more about the speed of such triggers. But I can't imagine that it would take 10 seconds. That's a *long* time in computer time.

I'm still not seeing how the color trigger and your event are related at all, and yet you said that you didn't get the delay until you added the color trigger. So now I'm *very* confused. Because you also said earlier that just disabling the onKilled event also got rid of the delay.

Posted: Mon May 05, 2008 11:32 pm

Well very rarely is a new item added... but the kill count goes up quite frequently.

Seems I was mistaken about the event disabled resolving the lag. Since it now seems to not be the cause. (same lag disabled or not)
I think it just coincided with text the color trigger was not firing on.

(I had assumed the event was the cause, because after each hang i would see the kill message from the mud.)

But when i turn the color trigger off there is no lag at all.

I dont really see why they would interact either.

Posted: Tue May 06, 2008 3:04 am

How many items are in the @myskills that you are using in the color trigger? If you can give us a dump of that variable, then I can try it here to see what kind of lag I get with it. It's possible that there is some bug that is causing the trigger regex to be recreated all of the time instead of cached.

Posted: Tue May 06, 2008 3:10 am

currently at 1081

Posted: Tue May 06, 2008 3:23 am

Um, ok, wow. I'll test that tomorrow and let you know what I find. For people who understand regular expressions, what CMUD is doing is converting your

Posted: Tue May 06, 2008 4:49 am

Having several trigs like that back in zmud used to causes slowness even with shorter lists.

Since I'm mentioning zmud, I'll go the old format:

#TR {{@enemies}} {#CW 12}
#TR ((@allies}} {#CW 12}
was fairly standard for most people, but when I tried creating a whole bunch of lists.. to colour people with tradeskills, people in order, guild, city, enemy cities etc, it really bogged down the trig parser.

So I figure its not unlikely that a single LARGE list might cause lag also.

#LOOPDB @myskills {#ADDI mysKillsList {%key}}

Create a stringlist version of the dbvar, and try using that in the trig, to see whether it is quicker as a stringlist.

Posted: Tue May 06, 2008 9:04 am

Changing to a real stringlist does remove the lag, so is the database variable aspect that causes the trouble then.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Yes, keep in mind that the variable used in the pattern (ignoring what appears to be a typo in the name: mykills vs myskills?) is a data record variable and not a normal string list. So, in your conversion example, Zugg, you need the =N parts, too.

Either way, that's one heck of a lot for any single trigger to process.

Posted: Tue May 06, 2008 11:59 am

Yes it is alot, but I don't want to have two such large variables to keep track of.
I was trying to overload the usefulness of the database variable.

Is there a way that when a database variable is used like a stringlist, that the %values can be ignored and just use they %keys?

#TR {{%dbkeys(@myKills)}} {#CW saddlebrown}

Doesn't seem to work... are predefined functions in trigger patterns no longer expanded?

Compiled pattern shows unmatched braces

Posted: Tue May 06, 2008 12:57 pm

I think the syntax is %%dbkeys()

Posted: Tue May 06, 2008 1:12 pm

That fixed the compiled error, but its not matching anything.

<trigger priority="16000" id="16">
<pattern>{%%dbkeys~(@myKills~)}</pattern>
<value>#CW saddlebrown</value>
</trigger>

That makes it match, but now i have lag again.

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

Aha, I had forgotten that syntax. Thanks Fang!

This should probably be in another thread as a bug but I'll mention it here too.

(?:%%dbkeys(@dbvar)) as a REGEX trigger does work.
{%%dbkeys(@dbvar)} as a regular trigger does NOT work. Even if you edit it the way Shalimar has above. The first Item then must have a ( before it to match.

I added this little tidbit to the help files.