
The metascripts, being a toolbox of various functionalities spread over a handful of different scripts, sometimes don't get the proper announcement of new features or capabilities on any individual basis. Since they are intended to work together (with themselves and with other scripts), I decided to roll all of the updates into a single message. With that said, let's get to what you can do with them, now:
SelectManager Criteria Selection
SelectManager recently got the ability to use wildcards (or even full regular expressions) as a way of identifying sets of tokens. For example, the following formation would choose all tokens that began with the pattern "GoblinArmy" followed by any number of characters:
{&select GoblinArmy*}
Further examples will use this notation, so if you need a refresher, read this post.
Available Criteria
With this update, the tokens that are selected by a {&select} formation can be evaluated against a series of user-defined tests. The tests can require a condition (+), or conversely exclude based on that condition (-). The available conditions include:
Criteria | Description | Example |
---|---|---|
bar1, bar2, bar3 | Test the value of a token bar (1, 2, or 3). | +bar1 > 0 -bar2 >= 10 |
max1, max2, max3 | Test the max value of a token bar (1, 2, or 3). | +max2 > 15 -max3 <= 20 |
aura1, aura2 | Test the radius or presence of an aura (1 or 2). If testing the radius, use the numeric value as would be in the token property field (e.g., the value you see when you double-click a token and scroll to the aura section). | +aura1 +aura1 > 3 -aura2 |
color1, color2 | Test the color of an aura (1 or 2) -- implicitly requires at least a radius of 0; blank aura radii will not register for color testing. | +color1 = #ffe599 |
gmnotes | Test the contents of the gmnotes. | +gmnotes ~ 'Squad 10' |
tip | Test the tooltip of a token. | +tip ~ Cephalothrope |
layer | Test what layer an object is on (objects, gmlayer, map, walls). Selector usage by non-GMs is already limited to the objects layer, and for GMs the layer criteria defaults to be the objects layer. Therefore, this is only of use to GMs who explicitly want to include other layers and/or exclude the objects layer. | +layer = gmlayer +layer in [objects, gmlayer] |
side | Test the currentSide value for a token. Standard tokens (not multi-sided) have a currentSide of 0, while multi-sided tokens can be 0 or greater, depending on the number of images in the list. | +side = 0 -side < 2 |
(markers) | Test the presence or value of a marker on a token. | +bloodied -marked < 1 |
(attributes) | Test the presence or value of an attribute (implicitly requires that the token represents a character). This criteria tests the current value by default, but the current value can also be designated by current , cur , or c. Max values can be queried by use of max or m. To use an explicit designation, follow the attribute with any of the following characters: . or ? or # or | | +@hp > 10 +@spectralessence|max >= 10 |
type | Test the type of a selected object (token, card, text, or path). Note that for "token" and "card", we are actually testing the subtype of the object, but these are just ways to differentiate the potential objects that could be selected. | -type = path +type in [token, card] |
pc | Test the token to be a player character token. Note there is no system-agnostic, discrete test for whether a token is a player character. This test is as close as we can get. This criteria tests that the object is a token, is on the objects layer, represents a character, and that there is at least one non-gm player with controlling rights to the token. | +pc |
pt | Test the token to be a player token. Similar to the pc test, above, except that this one does not require that the token represents a character (i.e., a treasure token, a spectral projection, a non-sheeted vehicle, etc.). Because of that, this criteria will include all tokens that would also be selected by use of the pc test. | +pt |
npc | Test the token to be a non-player token. Again, there is no discrete test for this. This criteria simply requires that the object be a token and that there are no non-GM players with controlling rights to the token (or associated character, if the token represents a character). There is no implicit layer requirement. | +npc |
Using Criteria
To use criteria, include them in a {&select} formation in addition to selectors. The criteria will not work without selectors; the selectors gather the tokens that the criteria will then test.
{&select GoblinArmy*, +bar1>0}
Multiple criteria can be included. To be selected, an object must pass all criteria evaluation (think of them as logical AND operators):
{&select GerbilArmy*, +bar1>0, +layer in [objects, gmlayer]}
Multiple selectors can be included in the formation, and the entire set will be evaluated against all criteria included in the selection.
{&select GerbilArmy*, GuineaPigBrigade*, Ralph, +@hp > 10, -Trapped}
Criteria only affect the selectors in the same {&select} or {&inject} formation. Therefore, to arrive at a logical OR evaluation, you can utilize zero or one {&select} formation, followed by as many {&inject} formations as you wish.
{&select *, +npc, +bar1 > 0} ... {&inject *, +pt, +MindControl}
That would select all npc tokens with a bar1 value over 0, as well as any player token marked with the status marker "MindControl".
Available Comparisons
For those evaluations that are testing the value of the given criteria, the following comparisons are available:
- equals =
- does not equal !=
- greater than >
- less than <
- greater than or equal >=
- less than or equal <=
- includes ~
- does not include !~
- in in [value1, value2, ...valuen]
Fetch gets Deck, Text, and Path Properties
Fetch retrieves properties from game objects (tokens, pages, markers, characters, etc.). With the pending update, it can now retrieve text properties, path properties, and it will now expand the properties it can retrieve for a graphic that is a card.
Cards
For cards, Fetch can now retrieve any of the following:
cardname
deckid
deckname
These will work with any Fetch formation that returns a card:
@(selected.deckname)
@(-M1234567890abcdef.deckid)
Text Objects
Since text objects do not have a "name" property, the only way to select them is by using "selected" or the id of the object:
@(selected.font_family)
@(-M1234567890abcdef.text)
The available text object properties you can return include:
TEXT PROPERTY | FETCH SYNTAX TO REFERENCE |
---|---|
_id | id |
_type | type |
color | color |
controlledby | controlledby, cby |
(names of all players in controlledby list, separated by commas) | cby_names, controlledby_names, cby_name, controlledby_name |
font_family | font_family |
font_size | font_size |
height | height |
layer | layer |
left | left |
_pageid | pageid, page_id, pid |
(name of page) | page, page_name |
(first playerid in controlledby list) | player |
(name of first player in controlledby list) | player_name |
rotation | rotation |
text | text |
top | top |
width | width |
Path Objects
Similar to text objects, paths do not have a "name" property allowing easy desigation. Therefore, the only way to select them is by using "selected" or the id of the object:
@(selected.left)
@(-M1234567890abcdef.top)
The available path object properties you can return include:
PATH PROPERTY | FETCH SYNTAX TO REFERENCE |
---|---|
_id | id |
_type | type |
controlledby | controlledby, cby |
(names of all players in controlledby list, separated by commas) | cby_names, controlledby_names, cby_name, controlledby_name |
fill | fill |
height | height |
layer | layer |
left | left |
_pageid | pageid, page_id, pid |
(name of page) | page, page_name |
path | path |
(first playerid in controlledby list) | player |
(name of first player in controlledby list) | player_name |
rotation | rotation |
scaleX | scalex |
scaleY | scaleY |
stroke | stroke |
stroke_width | stroke_width |
top | top |
width | width |
New Script Package in 1-Click: MetaScriptToolbox
As mentioned, the metascripts are various scripts which bring added functionality (or backfill functional gaps) to a Roll20 game. They are developed, built, stored, and delivered as individual scripts since they have discrete functions: Fetch retrieves game items, APILogic provides conditional logic to a command line, MathOps allows for complex math operations, SelectManager allows for "virtual" selection of tokens, etc.
While maintaining the scripts this way gives you the maximum flexibility over what you would install to your game, situations sometimes arise where you might need one of the metascripts that you don't happen to have installed. Many solutions I offer on the forums might require 4 or 5 of the metascripts to make them work as described.
For that reason (and at the suggestion of The Aaron), I have put together a new script package and submitted it to the 1-click installer: MetaScriptToolbox.
The MetaScriptToolbox packages up all of the metascripts as dependencies from the 1-click, meaning that if you get the MetaScriptToolbox, you will automatically get all of the other scripts, too, as well as all of the libraries and scripts that the metascripts might rely on (like libTokenMarkers or libInline). There is no command-line interaction with the Toolbox; it simply exists as a way to easily get all of the metascripts at once.
Getting the MetaScriptToolbox
Game owners can get the MetaScriptToolbox (once it passes through the script merge this week), by going to the script panel for their game and picking it from the dropdown on the Mod Library tab.
What Is Included
Primary dependencies (the metascripts) include:
- APILogic
- Fetch
- MathOps
- Muler
- Plugger
- SelectManager
- ZeroFrame
Future Updates
Since you'd be getting these scripts from the 1-click installer, you will always have the latest updates for any of them. One limitation of the 1-click installer is that dependent scripts are only installed once -- when the reliant script (in this case, the MetaScriptToolbox) is installed. After that, all of the dependent scripts will be updated via any change in the 1-click library. However, if I later added another script to the Toolbox, it would not automatically install. For that reason, I have included a check inside the MetaScriptToolbox that tests whether all of the scripts it would expect to find (that is, all of the metascripts) exist in the game. If it finds any missing, it will prompt you with a message and ask you to install the missing mod script from the 1-click library yourself.