Dynamic Tutorial

Dynamic Collection

How It Works

The new dynamic console allows you to enter tests for various games which will run either before or after tests imported from sidekicks. These tests identify posts just like sidekicks do. If you run your tests first, you can actually modify how a sidekick performs. If you run your test after the sidekick tests, you can capture anything the sidekick may have missed.

To change the order that your dynamic tests run, see the options menu under Basic Tech Options > Dynamic Collection. Also see the section for enabling dynamic tests per game or app.

How To:

Every test has these parts or parameters:

title

This optional parameter lets you change the visible title of your test. It has no effect on the test itself.

appID

Supply the application ID of the game this test will be for. App specific dropdowns will repopulate with the bonus list from that game.

If the appID parameter is left blank or not supplied, WM will run the test for EVERY game it recognizes. In some cases that might be good, but generally not. In addition, a blank appID or selecting "all" will not let you choose any specific bonus types to return.

Search

The search parameter determines where in the post you want to collect information from. Each search type functions differently.

Below is list of types you can supply:

link: the test is run on the link text
url: the test is run on the link url
body: the test is run on the body text of a post, which includes the following: title, caption and desc(ription)
title: the bold text on top of a post. Does NOT include the msg portion.
caption: normal text below the title, not all games use this. See also desc
desc: normal text below the title, not all games use this. See also caption
html: the test is run on the whole post contents. In WM 2, this is not actually the html of the post, but a jumble of all the other searchable sections of the post.
either: you can do both the link test and the body test in the same line, in that order.
msg: you can test for text in the message portion of the post. The section above the post where users can add their own text. This is NOT included in a body search.
img: the url for the image that goes with the post. Not all posts use this field. Mostly that is a mistake on the part of the game engine to attach one to the FB database.
fromName: the name of the person who created the post case.
fromID: the id of the person who created the post.
targetName: the array of people the post targets, name form.
targetID: the array of people the post targets, id form.
canvas: the location on facebook where the game runs, for instance farmville="onthefarm"
likeName: the array of people who like the post, name form.
likeID: the array of people who like the post, id form.
comments: the text of all comments attached to the post
commentorName: the array of people who commented on the post, name form.
commentorID: the array of people who commented on the post, id form.

To select a search type, simply click on the search type's text. It will highlight and you will know it is selected. You can also move search types around so they will be tested in a specific order. Don't worry about moving around types you have not selected. If you move away from this dynamic test and come back, all your selected entries will be on top of the list in the order you set them in. You may select any number of search types from the list.

sub type

Subtype is not actually a parameter, but a mode of functionality. The options are:

standard: You must enter one or more lines of text into the displayed "find" list. See find below.
subTests: You enter a single text into the displayed find box. The text may include an insertion point denoted with "{%1}" into which a list of subtests is created using the subTest list box displayed. The subTest list box otherwise works exactly like the find list box. See find below. See also a subTest's effects on the ret parameter below.
subNumRange: Like the subTests option, you enter a single string into the find box which may include an insertion point. Unlike the subTests listbox, the subNumRange option allows for a range of numbers to be inserted into the find string. Use the start and end number boxes to define the number range. See also a subNumRange's effects on the ret parameter below.
regExp: Unlike using a list of texts or insertion points for subTests, this option allows you to supply a registered expression. If you need help building registered expressions, I suggest looking it up on google. A registered expression can be much more useful than subtests to somebody who understands regExp notation. In this option you enter a single line which is in the regExp notation. See also a regExp's effects on the ret parameter below.

find

In the standard function of this console, you are offered a listbox to populate with your own search texts. To add a text string to the list, simply type in the box and click the plus button to add it to the list. You can add as many texts to the list as you want. When tests are processed, your list will be run in the order supplied, so you are offered options to move the texts around in case it would make a difference. For instance pea will be spotted before peanut and will affect the outcome of your dynamic test if not controlled by order. Enter data such as "hamburger" if you are looking to collect a hamburger bonus item.

When you use the subTests or subNumRange mode, you are offered only a single text box. This text string may include an insertion point marked by a "{%1}". See the subType parameter above for details.

In the regExp mode, you are again offered only a single text box, but instead of a simple text string, you enter a registered expression. Enter the registered expression as text without the beginning and ending "/" character. You may also not enter a list of modifiers after the expression. The text is converted to a registered expression when the script runs and will have only the default modifiers applied to it.

ret

The "ret" parameter is the return value to pass back to the identification function.

The return value of each test can either be a known magic word, a known value from the sidekick you use, or can be left blank. Feel free to study the return values from the sidekick you want to assist and pass those same return values. You must have an appID selected to pick from the sidekick's return list.

When you leave the "ret" parameter blank, the script will automatically return the magic word "dynamic", which is simply telling the script to collect that bonus. If you return any entry from the sidekick's return list, you also have to make sure that option is checked in the option menu or it will not collect anything.

If you use either the subTests or subNumRange sub type mode, the return value can include the same insertion point "{%1}" as was used in the find string. In addition, whatever was inserted into the test string will also be inserted into the return value. For example, if you used a subTest "adopt {%1}" with the following tests: pig, cow, horse, dog; you would test for each animal adoption text and return the one found. If you also had your ret parameter set to "animal_{%1}" and the string "adopt dog" was found, the return value would actually become "animal_dog".

If you instead use the regExp sub type mode, the return value by default is set to whatever is matched by the registered expression. That means the ret parameter DOES NOT default to "dynamic" this in this case.

In the case of subtests and registered expressions, whatever you enter in the ret box will override the defaults, as expected.

Below is a list of magic words the test can return. Magic words are prefixed by a "*" in the dropdown and will appear even for tests that do not supply an appID.

dynamic

When "dynamic" is passed back, the identification process won't flag the post with the proper "what is this" text. Instead, it will just tell you its being dynamically grabbed. Any post flagged with "dynamic" will simply be attempted. There is no option in the options menu to enable or disable simply "dynamic" flagged items.

none

When "none" is passed back, the identification process skips tagging the post and moves on to the next test. This is useful for creating subtests (see below), but otherwise is a waste of time.

exclude

When you "exclude" a post using a test, the identification process halts and marks the post as something you don't want anything to do with. It wont be processed or recorded in history.

send

When you return "send" or the word "send" followed by other text, such as "sendenergy", the script knows you are defining the post as a send-type post. If the sidekick you are assisting makes use of the "sendall" option and that option is enabled, then that post will be processed.

doUnknown

When you return "doUnknown", its the same as telling the identification process to halt and that you do not know what the post is. But, in the event of returning this value, if the doUnknown option is checked for that sidekick, it will process the post. This is not actually all that useful since the post would have been identified as "none" and converted to "doUnknown" if you had that option set anyway.

wishlist

When you return "wishlist" the script knows to not hide this post when clearing unwanted posts if that option is enabled in the Options Menu.

note

This parameter (on another tab of the dynamic console) is just for you. If you want to make a note of what your test does, you can use the "note" parameter, like in the example above, to tell yourself. Notes are not part of the identification process.

Other

If you have carried dynamic tests created in earlier versions of WM to the console, the now obsolete (yet still functional) parameters of your tests will appear in the other tab as a list of parameters you can edit. There is currently no option to remove these parameters, but you can delete the test and built it anew.

Parameters filled in on the dynamic console's data tab will override any older obsolete parameters.

Current Issues

There is a bug where if you have never used dynamic tests and you try to add one, you will not be able to edit that test. Simply restart the WM after choosing an appID for the test. This issue will be fixed AFTER I get my forms library created, when dynamics and priorities are more object oriented.

If you delete the very last (or top branch) in the test tree, you will not have an option to add a new test. However, by default, the WM script gives you an empty test to work with. Simply refresh the WM script and you will see your new empty test entry. See also the previous issue because it may apply to this newly added empty test entry. This issue will also be fixed after I get the forms library finished.

Suggest Something

While the process WM uses to identify posts is fairly complete, if you think of anything that the Sidekick Tutorial did not cover and that you think people might be able to use, please leave a comment below, or in the comments section on the Sidekick Tutorial.

Share It!

Think you have something really neat or useful to put in the dynamic grabber? Share it on the Dynamic Sharing page.