Zugg Software :: View topic

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Is there a definitive guide to zMUD optimization, specifically triggers and any thing related to keeping zMUD running fast? I have gained some insight through searching the forums in the past but I am wondering if anyone has gathered all of the tips and tricks and put them together in one place. If not, is there any interest from some of you guru types to want to try and put one together?

Posted: Fri Jan 06, 2017 3:23 pm

Tighten up your patterns to be as specific as possible...
Well the #WAIT command did not work as intended in zMUD, far better to use #ALARMs.

Most of the issues have been fixed in the more recent product, CMUD.

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Thanks for the reply Shalimar. I am looking for something a lot more specific and in depth. Laughing

There is a dozen different ways to go about using Zscript to get something done, what I am looking for is what the community has found over the years to be "best practices" for scripting in zMUD. I would be surprised if such a compilation of information hasn't been put together before. The help files give very basic examples and none of it to do with optimization.

As to cMUD I own it also, but the mud I play has a lot of zMUD users still. I write zMUD scripts that I share with the community over at WoTmud, eventually I will port everything I have done over to cMUD also, but first I'm trying to get my zMUD scripts as tight as I can get them.

Taziar Medakan @ WoTmud

Posted: Sat Jan 07, 2017 1:08 pm

That's just it, there are so many ways to go about it.
We here try not to stifle people's creativity be saying there is a 'best' way to do things.
Now if you are having trouble trying to get a specific thing done, we can offer suggestions on how to make it work at all.

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

I have spent 100+ hours reading and searching the forums in just the last year and I want to thank you Shalimar. You have tried to answer and help on almost every recent post. Truly, thanks for continuing to try even as the rest of the community has seemed to dwindle.

Tonight when I get home from work I will try to post a bunch of examples and questions to explain better so you might understand more clearly what I mean.

Thanks again!

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Here is a great example of what I am talking about: http://forums.zuggsoft.com/forums/viewtopic.php?p=79739

Pay particular attention to Zugg's responses and how he describes how Zscript triggers are optimized and #REGEX triggers use the PCRE library and are not optimized. Zugg says that #REGEX should only be used as a last resort if you can't do something with a normal trigger. This is a great example of what I mean as "best practices". Knowing this, you would never give someone the advice to use a #REGEX trigger if a normal #TRIGGER would work.

My original post is just asking if anyone in the community has put together a list of this kind of information to help others optimize the way they use zMUD scripting.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

If you read further Zugg clarified that particular point. I don't recall exactly what version of zMud first switched, or possibly not until CMud, zScript trigger patterns are converted into regex and then compiled by the PCRE. You can test this by renaming the pcre.dll and you should find that all triggers cease to work.

I believe zMud retains the compiled pattern so that the PCRE compile step only needs to be done once for each trigger, again that optimization might have been introduced until CMud. However, using %match, %regex, or %subregex must do that compile step each time it is called.

In short, the zMud optimization guide is switch to CMud.

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Thanks for joining the conversation Vijilante. Thanks for catching that, I misread that post originally. So #trigger and #regex performance are the same, right?

Since it doesn't sound like there is a performance guide do you guys have any tips, tricks, or advice to pass on regarding zMUD specifically?

Does using the trigger options: case, notrig, and verbatim whenever possible increase trigger performance?

Can anyone provide more examples of how notrig option works exactly, the help files don't explain it well enough for me to feel like I fully understand.

Exp triggers should be avoided in zMUD correct?

Arrays should be avoided in zMUD correct?

Thanks again.

When I finally do have some cMUD questions I will post those in the cMUD section. Cheers!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Arrays should be avoided in both zMud and CMud as they are COM objects and access external libraries on a slow interface. They should only be used when they are needed for other accesses on the same slow interface.

Expression triggers work alright in zMud, but I can't recall the exact testing moment. {a=1; {test exp triggers};#SHOW something;(end of code)} versus {a=1; #SHOW something;(end of code);{test exp triggers}}

Controlling case and verbatim on triggers makes only a small difference on pattern matching speed. Flagging NoTrigger makes a big difference if your trigger is using #ECHO, #SHOW, #SAY, or #PRINT; otherwise it is completely irrelevant.

And that is why there is no optimization guide for zMud's version of zScript. It is very difficult to provide any sort of hard and fast rules.

About the only constant sort of rule I can say is make your scripts as small as possible, which has the horrible side effect of complete illegibility. Shorten names for everything you can. Go down to 1 letter if possible. This is because the entire script has to be copied with references like %1 being replaced with text, and then it parsed for execution. Looping though something has the same parsing to go through each time. Look up "JavaScript mangling" and you may find a good explanation about this effect. CMud completely eliminates this penalty and then provides other ways to massively optimize code.

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Good information, Thanks Vijilante!

Can you explain notrig a bit more?
I notice that #ONINPUT triggers automatically default with the notrig option where normal trigger do not.
You say above that notrig only helps when using those specific commands in a trigger, does it matter if the #SHOW, #SAY, ect... are in the trigger itself or are called by an #ALIAS from the trigger?

Talking about keeping scripts concise I have a question.
We use a script a community member wrote a long time ago to search for current room name in our map and then teleport map position to correct room.

You have seen it here: http://forums.zuggsoft.com/forums/viewtopic.php?t=38906

Would taking this and breaking it down into smaller #ALIAS sections and #ABORT-ing out of it when a match is found be an example of what you mean by making scripts smaller?
Would the #ALIAS sections only get parsed up to the point of the #ABORT instead of the entire trigger as it stands now?

Should I be making my commands small as possible also by using the shortest abbreviation? #TR for #TRIGGER, #VAR for #VARIABLE, ect..??

Another question, when using %mapquery to find the room name in the above link'd script it currently searches the entire map database for the name to match, about 300 zones at 100 rooms per zone. If I change the %mapquery to first search the current zone only is that going to give any noticeable performance increase in the search? Or does it not work like that?

Anything else you can think of on the subject would be awesome.

Again, Thank you.

Very Happy

SubAdmin Joined: 18 Nov 2001 Posts: 5182

An alias called from a trigger is part of the same execution chain and is therefore an output of that trigger.

Generally you should not create complex settings from within a script. Even temporary alarms and triggers can be totally eliminated using multi-state systems with a manual state to lock out the rest of the trigger. #VAR can be replaced using var=something.

Changing the %mapquery in that script to target only 1 zone won't help anything because the whole database has to be searched to find which entries have the correct zone number. Changing the query to handle both name and description at the same time would be an improvement.
FoundRooms=%mapquery (%concat("(NAME = '", @FindRoomName, "') AND (DESC LIKE '", @FindRoomDesc, "%')"))

That particular script has many things wrong with it and can be improved considerably. I won't get into all of it. Breaking it into smaller aliases could be beneficial, but not when you start adding #ABORT. Use good flow control. Put the portion to search by exits into a separate alias and then only call that alias when it is going to do the search. Don't go backwards to change line colors with the #COLOR command, output them in the correct color in the first place. And WTF is this %char(32) at the start of #SAYs, if you want a space there use quotes. " Failed to retrieve room info!"

General optimization rule for all languages...don't repeat code that does not need to be repeated.
Bad:
#FORALL @RoomsFoundByDesc {#IF (@frsubexits(@FindRoomExits)=@frsubexits(%roomexit( %i))) {#ADDITEM RoomsFoundByExits %i}}
Better:
FindRoomExits=@frsubexits(@FindRoomExits)
#FORALL @RoomsFoundByDesc {#IF (@FindRoomExits=@frsubexits(%roomexit( %i))) {#ADDITEM RoomsFoundByExits %i}}

Even better would be to get rid of the frsubexits function, improve the trigger so it captures just the exits, use %lower to match to the results of %roomexit, use %subchar instead of %replace to change to list format, and then:
#FORALL @RoomsFoundByDesc {#IF (@FindRoomExits=%sort(%roomexit( %i))) {#ADDITEM RoomsFoundByExits %i}}

Novice Joined: 04 Feb 2014 Posts: 42

Oh how I wish I had you in my employ for a week. :)

You're awesome for helping Vijilante.

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Thank you Vijilante, more great information. I plan on re-writing that script so any other suggestions are very welcomed.

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

If anyone has any more to add to any of the discussion in the above posts please feel free to contribute.

I am going to take all of the things I am learning and apply them to my script collection posted here: http://www.wotmudarchives.org/forum/viewtopic.php?f=8&t=2409

If anyone is interested in checking them out and willing to give feedback I'd be grateful. These are scripts that I have wrote or adapted from other community members over at WoTmud.

Once I finish off getting them polished for zMUD I will start work on transferring them all over to cMUD and learning all the optimization differences for that.

Thanks in advance!

Very Happy

Taziar Medakan

SubAdmin Joined: 18 Nov 2001 Posts: 5182

To avoid using #COLOR you would use either %ansi or MXP tags. The %ansi function has a smaller set of colors from which to choose. You can create a function to wrap the MXP for you:
#FUNC MXPColor {%concat("<COLOR FORE=", %1, %if(%2<>"", %concat("BACK=", %2)), ">", %3, "</COLOR>")}

I can create an example for the use of manual to block alarms or triggers, but remember that #T+ and #T- also work very well.
#TRIGGER "IDNeededToWork" {} {} {} "manual"
#COND {-60} {#SAY Sixty seconds are up;#BEEP} {alarm}

Then in a script that wants to activate the alarm:
#STATE IDNeededToWork 1

The benefits of using that method is that you don't have to put a #T- to shut it off, the shut off is automatic. Also it will be in the off state whenever you first load your session. Finally if you place all such triggers in a single class you can use #RESET to put them all back to state 0 in an atdisconnect or atexit alias (see Introduction to Aliases).

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

Vijilante,

I reworked this script with what I thought you meant by using #FUNCTION to wrap the MXP tags.
I added extra triggers to turn trackLineTrigger on/off just as an example of how I usually handle that kind of action.
The first two #ALIAS are just help files for users.

Thoughts, suggestions, expletives? :P

First here is an example of mud output with script off:

Novice Joined: 15 Dec 2015 Posts: 41 Location: Seattle

This seems to work well for coloring an entire line using the MXP wrapping:

#FUNCTION testMXPcolor {<color %1>%2</color>}
#SHOW {@testMXPcolor(colorName,Line to be colored text goes here.)}

To add a space in front of text line instead of using the weird %char(32) in find room script:

#SHOW {@testMXPcolor(colorName," "Line to be colored text goes here.)}

Is this what you meant Vijilante?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Yes about the MXP color. I forgot I have to disable something for my post to display correctly, I fixed that and you can read my previous post.

About those spaces at the start of a line:
#SHOW {@testMXPcolor(colorName," Line to be colored text goes here.")}
#SAY " %1 is an invalid color..."
And for a blank line all you need is #SAY or #SHOW by itself.