Zugg Software :: View topic - speed trade off

Wanderer Joined: 23 May 2001 Posts: 68 Location: Sweden

Hi,

This is a question that has lingered in the background for some time, particularly while I'm constructing some "mammoth" scripts.

In my case I'm often using stringlists to store values which I use "conditionally" in other triggers, for example:

#TRIGGER "{@stringlis1} is here." "Say hi." stringlist1 may contain all my clanmembers' name.

QUESTION 1: Does usage of stringlist in this fashion slow down my zmud? Would it be faster to make 10 individual triggers (assuming I have 10 names stored in my @stringlist1)? What is the breakeven point between using a stringlist and setting up individual triggers (stringlist contain 5 values, 10 values, 100 values,..., etc)?

QUESTION 2: How much does normal triggers that keep lurking in the background affect the performance of zmud? I mean, all this triggers that are "waiting" for a particular output from zmud window... surely, aren't they affecting the performance?

SUMMARY: I would really like to have some more information on how fine tune my triggers and script-building so to keep zmud running as fast as possible. Any information available on that one?

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

answer 1: NO, useing the string list is much faster as that sometimes alot of triggers will jam the system up.
*But even this is based on your cpu.

Answer 2:not at all, I know what you mean and I have alot of scripts but to my experience this has never slowed down the preforance of Zmud.
*If anything it speeds up my gaming experience.

Summary responce: Keeping track of all the stuff you got going on will help you later on when trying to problem solve conflicts.
Always test new triggers, aliases, macro's, etc in a seperate #class so that you can enable it and disable it at your choice. This will help when combating new conflicts.
Always back everything up to another character for storage.
And just to be safe export all of it to a "txt" document and keep it somewhere safe. Maybe a floppy disk incase of system lose this will prevent you from losing YEARS of work.

Beginner Joined: 01 Sep 2003 Posts: 19 Location: USA

Sorry to revive an otherwise dead topic...

I was working on fine tuning some large scripts last night and noticed that when I turned off all triggers the mud response was almost instantaneous. When I enabled all triggers again, there was a 1-2 second delay in mud response.

I then went through and disabled 1 class folder at a time and found a particular folder that appeared to be causing the delay. This folder has my healing triggers which are set up in stringlist form (i.e. as nostra mentioned).

If I leave this class enabled, the 1-2 second delay remains. If I disable it, the delay goes away. The class has about 30 triggers, with about half in stringlist form. I went through all triggers and "pruned" them to bare bone minimum necessities. The delay remains.

The only difference from nostra's problem and mine, is that my stringlists are like this:

{You notice a particular|there is a stinging sensation|you are unable to do that|you cannot move your arms|you are paralysed}

That would be the average size, smallest would have 2 partial sentences and the largest has about 13.

Would having stringlist 'sentences' cause such a delay?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

With much larger string lists there is the possibility that a small delay would be caused by the trigger being case insensitive. I have many triggers in my setup that are similar to what you describe, some even much larger. They are all made case sensitive though and I have no slowing caused by them.

Beginner Joined: 01 Sep 2003 Posts: 19 Location: USA

I followed your suggestion and made the TRs case sensitive, but there is still a noticeable delay on mud output. No such delay when I disable them.

Just to clarify, I'm not actually using a stringlist and %ismember. These are some of my original TRs that I haven't updated, and they have the {stringlist} directly in the Pattern line of the Editor.

Could this possibly be causing the delay?