The rules manager that comes with the new Wall Manager 3 is entirely different from the Priority and Limits manager of WM2. Above you can see that the rules no longer target just a single post by a single app. Instead, you can select a multitude of new validators and actions.

!! Warning !!

One big word or warning about the new rules manager: Please disable the rule before you go editing it. Rules are saved on the fly while you edit, so if you accidentally tell a rule to make an interval at a 1 millisecond timer that opens a post source, you are really going to be sorry. Definitely, disable rules before editing them and save yourself from being banned on facebook, or using your entire monthly bandwidth in a matter of minutes. You are warned. I would also extend the same word of caution to the editing of dynamic grabber tests, although they do not have the power that WM3's rules do.

Rule Details

Main Rule Parts

Rule Toolbar (icons)

Rules toolbars contain the following buttons:

  • Trash Can: delete current rule and all child rules.
  • Cracked Egg: hatches rule eggs, replacing the current rule with those rule eggs. See Egg Rules.
  • Return To Zero: resets associated limit counter to 0
  • Clone: copies the current rule and appends it to the bottom of the rule list
  • 3-petal Flower: Births egg rules without breaking the current rule. See Egg Rules.
  • Move Up: Moves the current rule up one step within the same tree level
  • Move Down: Moves the current rule down one step within the same tree level
  • Move Up and Out: Moves the current rule up one tree level
  • Move Down and In: Creates a new rule at the exact tree position of this rule. The current rule becomes a child of that new rule.
  • Curly Brackets: Displays the source code of a rule in a text box. You can then copy the text to share with friends, or otherwise make copies of the code.
  • Global: Top level rules can be made global, or removed from global status. Global rules display for all FB accounts on the current browser profile. Other users can make a global rule local to them, removing it from other accounts. This can be used as another way to copy rules from one account to another.

Title (title string)

The title of a rule is simply its name or description, for you, the user. It has no other effect on the rule than as a display name. Newer versions may allow sorting by name.

Enabled/Disabled (enabled boolean)

This part of a rule is handled by the checkbox to the left of the Title. A disabled rule does not affect any posts. In fact it is skipped over during rule testing. Exceptions exist for some functions called in the "Do Actions" section of the rule.

Please disable any rule while editing it. Rule edits are live and can cause mayhem while running WM during editing.

Expanded/Collapsed (expanded boolean)

This part of the rule is handled by the show/hide button to the top left of the rule. A collapsed rule is only collapsed visually. It has no other effect on the rule.

Limit (limit integer)

The limit value placed on a rule serves as a limit to the counter (see limitCounter below). When the limit counter reaches your set limit, the rule calls its own "onLimit" event (see Events below).

Unlike WM2's limit and limit counter, WM3's rules manager DOES NOT automatically shut down the rule. As mentioned above, it only calls the onLimit event for that rule. You get to decide what that onLimit call does. If you want the rule to shut down, add the action: "onLimit Disable Rule".

The limit value can be used as something other than a limit to the counter, if you so choose.

Limit Counter (limitCounter integer)

The limitCounter of any rule is just a counter that ticks toward its limit.

Unlike previous versions of WM 2, rule counters in WM3 do NOT tick up automatically. In fact, you need to capture an event and specifically tell the counter to tick on that event. This gives you the ability to tick the counter for a variety of factors. Previously, WM2 only ticked up when something was collected. Counters may now tick up or down, either by incrementCounter/decrementCounter or by supplying positive and negative integers.

As mentioned above in "Limit", WM3's limit counter does not disable the rule when it matches the specified limit. It only calls the onLimit event for that rule. You specify what that onLimit function does by adding the onLimit action to your rule. If you want the rule to stop on reaching the limit, add the action: "onLimit Disable Rule".

The limit counter can be used as somthing other than a counter toward the limit, if you so choose.

Validators (validators object) "For Activating Objects"

Validators are entries that test each activating object at certain events to see if the rule applies to that object at that certain event. Validators are shown on the display under "For Activating Objects:".

To match any given object, ALL validators must be true about that post. There is no 'OR' option.

To simulate OR, you need to make two or more rules. Alternately, selecting multiple items in the search field has an 'OR' effect, but only for that line. Alternately, you can simulate 'OR' by using RegExp validation. Study up on RegExp notation using google search.

Validators have the following parts:

Search (search string)

The search entry of a validator works a lot like the dynamic grabber search parameter, and in fact, it has a lot of the same values. This is the part of an object or its related data that you want to ask a question about. Search parameters are well documented on the console; simply mouse over any element in the dropdown list for its description.

Selecting multiple items from the search dropdown is handled as if you want one OR another. To simulate 'AND', create two or more validators with different search terms.

Unlike the dynamic grabber, search terms are not moveable in the list, but order does not matter as much with the rules manager as it did with the dynamic grabber.

Operand (operand string)

The operand of a validator is generally equal to a mathematical or boolean symbol. Like the search parameter, the operand parameters are well documented in the dropdown by simply hovering your mouse over any entry.

An entry exists named "matchRegExp" which allows the user to enter "Regular Expression" format into the Find parameter (see Find below). RegExp format is handled internally by applying the /gi modifiers, which gives the user a "global" search (meaning the whole data portion regardless of line breaks), and "case insensitive" searching (meaning no matter what you are looking at, it is always going to find 'A' or 'a' when you ask for 'A').

An opposite version exists for all positive entries, denoted with the prefix "not". I feel they are self explanatory.

Since beta 5, "matchRegExp" remembers the matching text, as well as matching substrings. For instance, if you supplied a RegExp of '(?:color )(red|green|blue)' and tested against a post body including the text 'the color blue', then matchRegExp will remember the matching text as 'color blue'. You can retrieve that data for use in an action's third parameter by inserting '{%0}' anywhere in the textbox. As an example, if you had a rule action such as 'onIdentify setType {%0}', then the action would set the post's bonus type code to 'color blue'. Well who would want to do that? Probably nobody.

So here's the better part: because matchRegExp also remembers substring matches, you can also use those starting with '{%1}'. Using the same examples above, '{%1}' would be equal to just 'blue' because the RegExp we used contained a non-remembering bracket pair containing the word color and a following space, like this: '(?:color )'. That makes the first substring returned equal to the match minus 'color ', which is just what a lot of rules may want to help identify post types.

If you need more help with Regular Expressions, look them up on google. There is a ton of information out there to help you. Make sure you read specifically about using them in JavaScript, as other programming languages may have differing codes or extra shortcuts you cannot use here.

One very important note with rules is that multiple validators using the matchRegExp operand will pool their matches together. This can be confusing, so I will explain as best as I can.

Imagine you have a validator as in the above example, but you also want a second validator that detects an animal type, like 'body matchRegExp horse'. The word horse is matched, but there are no brackets in your test, so there are no substring matches. In total, your available data from both tests will look like this: where {%x}, x=0 gives 'color blue', x=1 gives 'blue', and x=2 gives 'horse'. Now you can supply the setType parameter with '{%2}{%1}' to set the post bonus type to 'horseblue'. Very useful when identifying posts with rules!

Find (find string)

The find entry of a validator is the text you wish to find in the object part selected under the search parameter.

All parameters have their content converted to the proper data type before testing. For example, if you supply text where a number is expected, then the validator will test using the number 0. WM has built in intelligence here, but you can actually break rules by supplying the wrong data type in some situations, so be nice to it. Likewise, if you want to match a boolean value, if you supply the word 'JimBob', it is converted to 'true' because something does exist. I've made it so the word 'false' should translate to 'false', but try to use 1's and 0's when possible.

Actions (actions object)

Actions entries are the effects you wish to place on matching objects. Each action is performed at a certain event, and so you have generally two parts for every action, and a third parameter for some cases.

Event (event string)

The event entry is the captured event to process this action on. When the event fires, that event instance is passed to the priority handler and tags the object which caused the event to occur.

Some events are not fired from posts and so do not have access to the post object. Know what object will be doing the activating before you release a rule to do your bidding, especially with intervals and timers.

Action (action string)

The action parameter of any action is the actual function to call, either upon the activating post, the rule itself, or also just a general function the main portion of the script can provide. Obviously there are certain things you would not want to do at certain events so use some sense here. There may also be some things you CANNOT do at certain events, and so trying to do them will probably cause some unexpected effects.

WM ignores the action if the action you wish to perform cannot be performed on the object type that activated the rule. For example, if your rule matched a feed object, there is no post object directly associated with it, so you cannot make an action that collects that post. So you cannot do this, "onFeedFilterOlderLimitReached setType horse".

Some actions require extra data, such as setColor. For that we need the third parameter (see Parameters below).

Parameters (parameters string)

The parameters entry for any action is the data that goes with the action to be performed. Few actions require extra data.

One action of note is the setColor action. SetColor can accept any CSS based color number (#BADA55), color name (pink, red, green, royalblue), or an internal CSS function (rgb or rgba). For more information on CSS colors, see CSS Color Names.

Another action of note is the setAsAccepted (and likewise setAsFailed). Normally setAsAccepted temporarily marks the post as accepted, giving it the proper color and causing the collector to not attempt collection. However, if you pass a parameter of "true" to the action, the rule will not only mark the post as accepted, but also store its acceptance code in your history, so next time you refresh, that post will already be marked accepted.

As of WM3 beta release 19, some options exist which require two parameters. One of those is setHostOption. In setHostOption, you have the ability to set an option in the host's options menu to a value, other than true or false, such as what enable/disableHostOption allow. With setHostOption, you pass the internal name of the host option in the first parameter, such as "autoliketimeout". In the second parameter, you pass the value.

Parameter boxes only display for those actions which require parameters. As of WM3b19, null parameter data is no longer stored, to save storage space.

There are special considerations for options menu time fields. Some time fields take exact values in seconds, or milliseconds, noted with an (s) or (ms) by that option in the menu. Other time fields take a special word/phrase or time format string. To see more about how WM uses time related words and formats, check out WM3 Time Formats;

Child Nodes (kids object)

Child nodes are processed during an event where the parent already matches. Child nodes are used to break down the search even further. For instance, your parent rule can test just against an appID, and then your child nodes can test against certain body text.

The order of operation of events from parent to child goes like this:

  • Event fires on top rule
  • Parent validators match
  • Child validators match
  • Deeper validators match
  • Deeper actions performed
  • Child actions performed
  • Parent actions performed
  • Try next top level rule
  • Event continues

Disabled child nodes are skipped. Collapsed child nodes are run normally; they are just collapsed visually on the console.

Egg Rules (eggs object)

Egg children are very different from other child nodes. When an event fires, egg children are NOT processed at all. They are basically in temporary storage.

To break them out, you need to call the "hatch" function of the parent rule. When hatched, egg children overwrite the parent rule, and the parent rule and its normal child nodes are destoryed. Below is a visual example:

Before Hatch

  • Rule 1
  • Rule 2
    • Egg Rule A
    • Egg Rule B
    • Egg Rule C
  • Rule 3

After Hatch

  • Rule 1
  • Rule A
  • Rule B
  • Rule C
  • Rule 3

Upon hatching, the parent rule calls its onHatch event at the last second.

Alternately, you can use the birth action of a rule, which takes a copy of all of this rule's egg children and places them at the same level as the activated rule. Below is a visual example:

Before Birth

  • Rule 1
  • Rule 2
    • Egg Rule A
    • Egg Rule B
    • Egg Rule C
  • Rule 3

After Birth

  • Rule 1
  • Rule 2
    • Egg Rule A
    • Egg Rule B
    • Egg Rule C
  • Rule 3
  • New Rule A
  • New Rule B
  • New Rule C


Yes, rules have a lot of buttons! But its not very difficult to use them:

The console starts with a plus (+) button which simply adds a new rule. It also has a refresh looking button that resets the limitCounter of every rule to 0. Then there is a hand button with an arrow coming out. This button converts all your dynamic grabber tests to new rules. It DOES NOT however remove the dynamic grabber tests. I want you to verify that the tests converted to rules properly before you manually delete the tests, but you do need to delete or disable the tests or you might be doing double work on posts. And finally, there is an icon of a bracket pair with an arrow going into them. This is the import button which allows you to import JSON formatted text from which rules will be created. Each rule has a similar bracket button which gives you the type of data you need to enter here. This lets you save or share rules with your friends, or even with the people making your sidekicks for you.

Other buttons on a rule include: add validator, add action, add child and add egg. These are self explanatory.

Validator and action lines include buttons for: clone, remove, move up and move down.

Child and egg child rules include all the same buttons as a top level rule.

Validator Search Explained

Validator searches offer so many options, it can be confusing, and not just because the list is long, but because the list contains parts for posts, feeds, apps, feed filters, rules and more. While search entries are explained when you hover your mouse over them, here is a list of parts that go with each object that is NOT a post:


  • acceptCount: The count of accepted post collection attempts for this app.
  • activatorType: Equals "app" for apps.
  • appID: The fb-given id for this app.
  • appName: The fb-given name for this app.
  • canvas: The 'namespace' parameter for this app.
  • enabled: If this app is enabled on the 'manage sidekicks' panel.
  • failCount: The count of failed post collection attempts for this app. Includes timeouts.
  • totalCount: The combined accept and failed counts for this app.
  • typesPaused: An array containing any bonus types (post 'which' field) that are currently paused, and so not being collected. Because this is an array, not text, you should only use the "contains" and "not contains" operators. Using others will probably crash the rule and cause an error in the debug console.


  • activatorType: Equals "feed" for feeds.
  • enabled: If this feed is enabled on the 'manage feeds' panel.
  • id: The fb-given ID of the user associated with this feed.

Feed Filter

  • activatorType: Equals "feedFilter" for feed filters.
  • enabled: If this feed filter subobject is enabled on the 'manage feeds' panel. This does NOT take into consideration if the parent feed is disabled, so a feed filter of a disable feed that is not specifically disabled will report enabled. Test for both if you want the correct info.
  • appID: The fb-given ID of the app associated with this feed filter.


  • activatorType: Equals "rule" for rules.
  • enabled: If this rule is enabled on the 'manage rules' panel.
  • limit: The limit number of the current rule.
  • limitCount: The limit counter number of the current rule.
  • parentLimit: The limit number of the parent rule, if one exists.
  • parentLimitCount: The limit counter number of the parent rule, if one exists.


  • activatorType: Equals "unknown" for generic activators, though sometimes it is global or from the main script body.
  • currentTime: A posix timestamp in milliseconds representing the current date-time. This is not text, so you can't ask it what day of the week it is without already doing some serious math yourself. If you know what time it is now, and you know how many milliseconds away next Wednesday is, you can make rules wait to do something until next week when you might be on vacation and cannot otherwise babysit the WM.


All other search types are for posts, and that includes some already mentioned as well. Mouse over each search term for better details about each.

Activating Objects Explained

Events are fired by the WM host at certain points in the script process. Each event is directly tied to an object type, which you can use activator searches to obtain, using the "activatorType" selection. Once you know that, you are safely free to perform your actions for a rule.

By default, the only activators you will ever see are posts, rules, occasionally a feed filter, and the heartbeat (explained in depth later). However, in the options menu, under 'Host Options' > 'Rules Manager' > 'Heartbeat', you can choose to have the heartbeat activate all the objects of a type at once. This allows you access from various objects on a timed schedule.

Here is a list of events you can use for each activating object type:


  • onLimit: This event fires when the rule is at or over its limit any time the limit count is increased but not when it is decreased. One exception is that you can pass negative numbers to the 'incrementLimitCounter' function and you will fire this event if the rule is still over limit after your negative number is added. The same is true with negative numbers and 'incrementParentLimitCounter'. In this event, you have access to whatever object cause the limit to increment. That could be the rule itself, or it could be the post that was counted. You need to know that when you build the rule.
  • onHatch: This event fires when a rule is hatched, but AFTER the current rule is already destroyed. You should not peform actions on the activating rule at this point. The object you have access to is either the rule itself, or if hatched on a timer or interval, the object that created the timer or interval. Other scenarios do exist.
  • onTimer: This event fires when the timer has reached its end. The object you have access to here is the object that initially created the timer, which may or may not be the rule object.
  • onInterval: This event fires each time the interval has reached its end. The accessible object here is the same as for timers.
  • onBirth: Similar to onHatch, except the rule that does the birthing still exists.
  • onRuleCreated: This event fires either when you first make the rule, or every time the rule is reloaded when the script restarts. The accessible object is ALWAYS the rule itself.


  • onSidekickDock: This event fires when a sidekick docks. The accessible object is the app for which the sidekick collects bonuses. There are only a few things you can do with apps/sidekicks.

Feed Filter

  • onFeedFilterOlderLimitReached: This event fires when a feed filter notices that a fetched post in a packet has a date which is older than your user-set older limit time (in the options menu). Feed filters that have reached their older limit do not attempt to fetch posts in that directly anymore, and so you may want to harness that knowledge for your rules. The only accessible object from a feed filter is the filter itself.

Timers and Intervals Explained

When you create a timer/interval with a rule, that timer is linked between two objects: the first being the rule, and the second being the object matched by the validators. The only exception being for onRuleCreated having access to only the rule itself.

Whenever the timer/interval reaches its end-time, whatever you do onTimer or onInterval can only affect the rule or that attached object.

Here's an example: Lets say we want to capture a failed post and then pause collection for the associated app for 1 minute, then unpause it.

  • where 'which' equals 'horse'
  • onFailed pauseApp
  • onFailed createTimer 60000
  • onTimer unpauseApp

In the example, what happens is this:

  • validator matches only posts where the bonus type exactly matches 'horse'. It now remember the matched post object
  • if collection on that post object fails for any reason the related app is paused. We know the related app because the post object knows from which app it came, but we are still relying on the post object, not the app object
  • in the same moment the app is paused, we also create a timer for 60 thousand milliseconds, or 1 minute (check me, is that right?). The created timer remembers the validated object which caused its creation, which happens to be the post object
  • when the timer reaches its end, we unpause the app using the timers remembered post which in turn remembers its app

Any time you create an action, that action is targeting whatever object activated the rule. Any delayed effects such as intervals and timers remember what that activator was. This is the only reason they can do anything when they reach their limits, otherwise the only thing they could affect would be the rule itself, which is certainly not very useful. Remember all that and you will be just fine.

Heartbeat Event Explained

Normally, a rule must create a timer or interval on which to count down time between things like controlled collections. Meaning that for some apps, you might want to micro-manage everything that the sidekick is doing for you and so you create wait periods and lots of little clockwork parts to help you accomplish that goal. These rule intervals and timers can do a good job, but what if you need a global timer? Well then there is the global onHeartbeat event!

In your options menu, you can set the rule manager's heartbeat interval, which is by default 1000 milliseconds, or 1 second. So every second the WM host has a heartbeat, pumping an event to every type of object you have selected for that heartbeat to affect (also in the options menu, same location).

Now here is where it can get confusing, so pay attention:

If you select to affect posts, then the heartbeat will cause the onHeartbeat event to fire for ALL posts at once (asynchronously). The activating object of the onHeartbeat event is the post getting affected. The rule activates for any post that matches the rule's validators. Because the heartbeat happens on a tight interval, you definitely don't want to do some things, like fetch posts, autolike a post, or create intervals and timers. Enabling onHeartbeat on all object types can cause a madhouse in your rules, so if you do, make sure your rules also have a validator that restricts its object type, like 'where 'activatorType' equals 'post' -> onHeartbeat incrementLimitCounter' Beware enabling 'affect' for all object types. If you have 100 posts fetched, and you have 10 rules, that is 1000 events to fire all at once just for post-to-rule activation, plus 10 for the global-to-rule activations. Now add to that nested rules, if you have any. Then add 1 for every sidekick you have installed, 1 for every feed, and 1 for every feed filter. This can really get out of hand and bog your machine to a grind. And finally, the biggest thing to remember here is that if you do not turn on heartbeat effects in the options menu, the only rules that will ever be affected by onHeartbeat will be rules that DO NOT have validators, except validators that check 'currentTime'. This is because there is no post associated with the global heartbeat. If you attempt to do onHeartbeat on posts without enabling them, the rules never hear the call.

Bonus Type Queries Explained

When a sidekick dev makes a bonus type in their script, they might simply supply 'horse'. That is all fine and good, but what if another sidekick dev also has a bonus type of just 'horse'. Well that would mean that if you selected 'horse' in your options for collection, you would collect all 'horse' type bonuses for every app you had a sidekick for. That's no good. So what happens is, when a sidekick docks to the host, the host appends the appID of that game to the front of every bonus type, every menu item, ANYTHING that sidekick passes to the WM host. That may be confusing already, but lets see what happens:

  • There is a 'horse' entry in the PT sidekick
  • The sidekick docks to the host
  • The host takes the appID from the PT sidekick, which happens to be '266989143414'
  • The host turns 'horse' into '266989143414horse' for disambiguation purposes
  • When you select 'horse' in the options menu, you are really telling WM to collect bonuses of type '266989143414horse'

So now we have the true bonus type ID for a horse in PT. That means any rule or dynamic grabber test where you search the 'which' or bonus type for 'horse', you really need to put in '266989143414horse'. Luckily, the dynamic grabber in WM2 automatically appends the appID in front of whatever you pass it, except for special words like 'dynamic', 'none', or 'exclude'. WM3's dynamic grabber goes one step futher and only prefixes the bonus type with an appID if the appID isn't already there. You'll also notice the dropdown for selecting bonus types in WM3's dynamic grabber will show you the appID prefix when you make a selection. The rules manager, however, does NOT do that for you. The reason being that WM3 allows users to make user-defined bonus types. These user-defined bonus types DO NOT have to have an appID prefix. While its suggested for types you want associated with an app, its not required because you MIGHT want to make a generic bonus type for multiple apps on purpose. Don't ask me why, it was your idea. So, what the rules manager does is either have you add the prefix yourself, or omit the prefix, OR you can use an insertion point text of '{%appID}' and the rule will absorb the appID from the captured post into that location. Say you want a rule that catches a new post that the PT sidekick has not yet caught, you would do this:

  • where 'body' matchRegExp 'wrangle up one of Bess' new ponies'
  • onIdentify setType '{%appID}horse'

That will take all posts for any app where text matches the 'wrangle up one of Bess' new ponies' part, and mark them as a 'horse' bonus type for the PT app. That might not be exactly what you want, but its just a simple example.

Remember, if you assign something a bonus type that does not exist, like if you typed it wrong or did not prefix an appID when needed, then the captured post will have an 'idText' of 'undefined'. That should be your first indicator that something is wrong. Check that 'idText' in developer layout and also make sure you didn't supply a bonus type id for something simlar, but not the right bonus type id.

Creating Rules From Posts

Each post has a button that allows you to create a rule from a post. Well that is not exactly what it does, and its certainly not a complete process. What it DOES do is:

  • Create a rule
  • Title the rule in relation to the post it is based on
  • Create a temporary connection from the rule to the post it is based on
  • Create a list of validators for each of the following post fields
    • appID (match exactly with 'equals')
    • title (generic match)
    • caption (generic match)
    • desc (generic match)
    • link (generic match)
  • Create a to-do list for this post
    • onIdentify setType 'dynamic'

So as you can see, it does a lot of things, but what that gets you is ONLY that post, nothing more, and not posts like it (unless they are exactly like it). What you need to do is go through the validator list, decide which ones you really want, delete the ones you don't, and if needed, add more. If you leave the validator texts as they are, the rule is going to be fairly useless. Check each validator's text and remove things like user names. Also do your best to shrink the text down to the bare minimum to detect a post type. For example, here's a caption text:

  • suzi needs some horsey punch to create sweet feed! share one and you'll get one too!

Here's what you probably need:

  • 'horsey punch' and maybe the word 'share' or 'needs'

You can probably remove all the rest, including the validator for title, desc, and link. With a few modifications, you can make your rule look like this:

  • where appID equals '266989143414'
  • and caption matchRegExp 'horsey punch'
  • and caption matchRegExp 'needs'
  • do onIdentify setType '266989143414sendhorseypunch'

A few final notes on making rules from posts:

  • Rules stay connected to the post object until you refresh the browser or leave the page
  • Even after a post is 'cleaned', posts now stay connected to the rules (as of beta7)
  • Rules connected to a post have a new button that allows you to 'Capture Text From Linked Post'. What that does is set the find value back to whatever the value of that post part was. Again, you will want to edit that text to make it work the way you need. This is just for if you make a mistake, or forgot the post part text.

And now, lets make it a bit more complex, and more useful at the same time...

Example of Using Insertion Points

If you wanted to be a bit more crafty, you could do this instead, and get the same result:

  • where appID equals '266989143414'
  • and caption matchRegExp '(horsey)(?: )(punch)'
  • and caption matchRegExp '(needs|share)'
  • do onIdentify setType '{%appID}send{%1}{%2}'

For anybody confused about RegExp capturing parentheses, anytime you put something in (), the expression remembers whatever is in parentheses, EXCEPT when you do this (?:horsey) it does the opposite. If you then count how many parenthesized items you have, there is:

  • 1) horsey
  • 2) punch
  • 3) needs (which we dont even use)

So the setType parameter can simply be send{%1}{%2}, which equals sendhorseypunch. BUT, you need to supply an appID prefix to make use of option menu selections, so we cheat and use the built in magic {%appID} prefix to mechanically insert that into the value.

For anybody keeping score on my accuracy, you probably already know that:

  • {%0} is equal to 'horsey punch' which we don't want because it has a space in it. That is because {%0} represents the actual match for the first validator, ignoring substring matches. You often won't want the full match, just a segment.
  • {%4} is also 'needs', and it would be safer to use {%4} rather than {%3} in most cases.
  • {%3} actually represents the full match for the second validator, and as mentioned above, you won't want that in multiple word cases.

So how do you know what numbers to use for complex cases? Well, practice ... and double checking is the key, otherwise, you really have no idea. One thing to remember is that when you have multiple validators, their match and string capture values get concatenated into a single array. Using our example above:

  • 0) validator 2 full match = 'horsey punch'
  • 1) validator 2 substring match 1 = 'horsey'
  • 2) validator 2 substring match 2 = 'punch'
  • 3) validator 3 full match = 'needs'
  • 4) validator 3 substring match 1 = 'needs'
  • note that validator 1 (where app equals...) does not use matchRegExp so it does not capture substrings

Knowing where one list ends and the next begins in that array is key to success in complex rules.

If this proves to be unusable by most people that actually want to use it, I may do something more textually complex, but more accurate, in a future version. For instance I might let you enter {%1:0} to get the second (index 1) validator's first (index 0) substring match, which would be 'horsey' in the example above.

If you provide insertion points beyond the range of captured substrings, the insertion point will be unused and remain in your value. Using our example above:

  • {%7} does not reference a substring match
  • so if you had: onIdentify setType '{%appID}send{%7}'
  • then your actual parameter value would be: '266989143414send{%7}'

You don't want that.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.