Back to Tips Page

/if command..now where to begin? :p

As you probably already know, /if is used as a comparison to match expressions (or see if an expression doesn't match. The utility of /if is just too strong to avoid learning how to use them, even basically.

MM's /if statement allows evaluating expressions as either equal-to (==), not-equal-to (!=), greater than (>), greater than or equal to (=>), less than (<), and less than or equal to (<=).

Syntax:
/if {Something[operator]Something} {then do this} {else do this}
   where "[operator]" is either ==, !=, >, <, =>, or <=
   the {else do} is not required and can be left out.

Basic calls are:
/if {Something==Something} {then do this} {else do this}
/if {Something!=Something} {then do this} {else do this}
/if {Something>Something} {then do this} {else do this}
/if {Something<Something} {then do this} {else do this}
/if {Something=>Something} {then do this} {else do this}
/if {Something<=Something} {then do this} {else do this}

Basic Rules:
 When To Quote?
In the comparison you often need to use quotation marks on expressions.

System variables ($0-$9, $AnyVar, $LoopCount, etc) don't use quotations.
   /if {$0==$1} {do this}
   /if {$0!=$MySillyVar} {do this}
Procs require quotations.
   /if {$0=="@WordCount(SomeText)"} {do this}
   /if {"@Word($0,1)"!="@Word($3,2)"} {do this}
..exception is, if you KNOW the proc's value is a pure number, you can eliminate the quotations.
   /if {$0>=@Math($MyNumber+1)} {do this}
..and if the proc is a check, such as @StrStr() or @WordCount(), as these return numerals.
   /if {@StrStr($0,sometext)!=-1} {do this}
Numerals don't use quotations.
   /if {$0=235} {do this}
Alpha text require quotations.
   /if {$0="Wilber"} {do this}

 And Or?
And (&&) and Or (||) are very useful to making multiple comparisions in a single statement. But you should avoid using more than one OR as they tend to mess up.
   /if {$0==1 || $0==2} {do this}
   /if {$0>1 && $0<=100 && $0!=50} {do this}
Unfortunately MM's OR operator isn't reliable enough for more advance use, so stick to the simple rule.. 1 OR in any statement. You can embedded more ifs as needed if you need more checks to compare things. You can reliably use plenty of And operators though.

Creation
 Think!
Think through what you want done. Have a good idea of what it is you are trying to accomplish before just diving it. I almost always picture the process in my mind before I write an if. I try to follow a somewhat logical procession to. Especially with embedded ifs. What I think will be true, but more on this later when I get to embedded Ifs.

 Those darn bracers
One of the biggest problem of Ifs, in particular long ifs with lots of commands, and other routines (and more embedded ifs) are losing track of where bracers go.
Personally I do all scripting in WordPad. And here's a few ways I construct Ifs. Say I want a script to see if Fred says somethingi with "mudmaster" in it...

 The Broken Code Method
This gets confusing, but I use this sort of method often, very often, with huge scripts. Breaking each section apart. This helps me not only build the script, but to see what I'm doing and where I'm doing it.

I turn the script on end..
   /action {trigger} {commands} becomes:
   /action {trigger}
   {
   ..commands going in here..
   }

   /action {%0 says, '%1'.}
   {
   /if {$0=="Fred" && @StrStr(@Lower($1),mudmaster)!=-1}
    {talk $0 Woo Mud Master!}
    {else do..}
   }

I don't need the {else do} in this case, so I eliminate it!
   /action {%0 says, '%1'.}
   {
   /if {$0=="Fred" && @StrStr(@Lower($1),mudmaster)!=-1}
    {talk $0 Woo Mud Master!}
   }

Now I just backspace everything, starting from the END of the entire process -- carefully so I don't delete stuff.
   /action {%0 says, '%1'.}
   {
   /if {$0=="Fred" && @StrStr(@Lower($1),mudmaster)!=-1}
    {talk $0 Woo Mud Master!}}

..backing up more...
   /action {%0 says, '%1'.}
   {
   /if {$0=="Fred" && @StrStr(@Lower($1),mudmaster)!=-1} {talk $0 Woo Mud Master!}}

..backing up more..
   /action {%0 says, '%1'.}
   {/if {$0=="Fred" && @StrStr(@Lower($1),mudmaster)!=-1} {talk $0 Woo Mud Master!}}

..backing up more, and done!
   /action {%0 says, '%1'.} {/if {$0=="Fred" && @StrStr(@Lower($1),mudmaster)!=-1} {talk $0 Woo Mud Master!}}

The big point with this method is to keep the actual "do" and "else do" areas somewhat seperate so you can keep tabs on those areas. If you can keep track of the bracers, you should be fine. Afterall, /if {This==This} {do} {else do} is only 6 bracers (more like 4) to keep track of. This is handy in general.. well if you can get used to it it is anyway.

Embedding Ifs
 What are embedded ifs?
Simply an If inside of another If, inside of an if, inside of...
Embedded if's add a lot of power to scripts, but also add a lot of headaches. They really get out of hand (bracers) quickly, and add tons of confusion to the script.
Try to keep it simple, and build slowly. If possible build a bit at a time and keep things small. And build logically. Have comparisons you think will be true up front, and the less likely things in the rear (so the action processes quickly).
Think out the process before hand, scribble notes, etc. Have a decent idea of how you want the process to go beforehand. A good mental picture of what you want, before you start, helps tons.
Basic rule: The embedded if IS the {else do} part. Stacking if's with seperators isn't embedding -- BUT this is a good method to use while learning to embed.
   /action {%0 says, '%1'.} {/if {$0=="Fred} {do};/if {$0=="Joe"} {do};/if {$0=="Sally"} {do}}
That's not embeded if's. But it's a good tool to turning it into one that is embedded:
   /action {%0 says, '%1'.} {/if {$0=="Fred"} {do} {/if {$0=="Joe"} {do} {/if {$0=="Sally"} {do}}}}

So why use embedded Ifs when the above first example does what the second one does? Because in the embedded one, as soon as the comparison is true, it does the DO section, and is done. Say Fred said something. In the first action all /if's are processed, even though Fred's DO fired. It's still checking $0=="Joe" and $0=="Sally". In the embedded action as soon as $0=="Fred" is found, it does the DO, and is done. Faster process, faster scripts, faster mudding! This is actually apparant in huge scripts. You can see MM slow down due to either poor if statements, or the comparison that was true was down at the end (again Logical process, think it out and put what you believe will match up front). (ok ok so maybe you can't see MM slow down, but I can, I'm magic! Although, I've seen it slow down.. on some of my huge scripts.

 Another trick I use for keeping tabs on bracers..
Using the above example.. I build it like such (in-line method):
   /action {%0 says, '%1'.} {/if {$0=="Fred"} {do} ..then add a bit more..
   /action {%0 says, '%1'.} {/if {$0=="Fred"} {do} {/if {$0=="Joe"} {do} ..add a bit more..
   /action {%0 says, '%1'.} {/if {$0=="Fred"} {do} {/if {$0=="Joe"} {do} {/if {$0=="Sally"} {do} {else do}

Now, that's how I build um, I've ended at the last "do".. but I'm missing bracers. Hrm now how many bracers do I need? Ahh.. Count Ifs.. there's 1, .. 2, 3! So I add 3 bracers.
   /action {%0 says, '%1'.} {/if {$0=="Fred"} {do} {/if {$0=="Joe"} {do} {/if {$0=="Sally"} {do} {else do}}}}

Key to this is to keep tabs on the DO sections, as those will potentially be filled with more commands and more bracers adding to the confusing. Keep tabs on those, and live becomes easier. Get confused and lost in the script, try breaking it apart in the "broken code" method.

General Tips

Work in WordPad (or NotePad, altough wordpad has search and replace functions which are handy). If I have a problem script, say a confusing action, I cut/paste just that one action that I'm working on to another session of wordpad. Editing it all by itself. Save it, load up just that action into MM, and see if it looks right in MM (via /groupact etc, or /editact, or /fedit act). If the rest of the script is good I load that up (or have previously) and test away. If it's messed up sometimes I use /fedit and the Ctrl+] key to find matching bracers. Or just delete it all from MM and re-edit in wordpad some more.

Leibniz has a nice trick he uses. Make sure you always make groups for your commands (I follow this practice for everything as well) /action {trigger} {commands} {GROUP}.. group everything you write. ..Load in the script you're editing, then do: "/writegroup somefile.txt" without supplying a group name (syntax is suppose to be "/writegroup {filename} {group}").. and anything grouped as {} will be saved to the file you've told it to write to. A quick look at that file will show bad scripts (or any good script, that's groupless). This works good, because writegroup has a bug in it that causes it to save anything that's not grouped up. Hopefully Aaron won't fix that :) heh. So you might see in your file you just did /writegroup to..
/action {Yadda Yadda %0 woohoo} {/if {blah=blah} {do} {/if {$stuff!=stuff} {do this}} {GROUP}} {}
..and you'd know that's a messed up action.

Back to Tips Page