Player Properties New to v2.0.0 Player properties can be retrieved with syntax very similar to character/token properties. Fetch syntax for player property retrieval starts with @(player. followed by the player identifier, the property you are looking for, as well as any default value you want to include (see Default Values ), and a closing paren. @(player.timmaugh.online) @(player.timmaugh.display_name) @(player.-M123456789abcdef.userid) The one exception to this formation is using the speaker syntax to get player information. If a player is speaking as themselves, use the standard speaker syntax (no need for the player identifier), and include the property you wish to retrieve: @(speaker.userid) @(speaker.playerid) Campaign Properties New to v2.0.0 Use similar syntax to get campaign properties, except using campaign instead of player . Also, since there is only one campaign object, you need not supply an identifier. @(campaign.page_name) Certain properties (like markers, playerspecificpages, and turnorder) are available, here, but have better handles for their data. These properties, coming from the Campaign, will contain all of the information in them, which may not be what you want. Marker Properties New to v2.0.0 Fetch refers to markers as the set of token markers installed for a particular game. These have a name, a tag, html for presentation, and sometimes a url. Markers are separate from "statuses" in that statuses refer to token markers that may or may not be assigned to a particular token. Think of markers as being derived from the Campaign, and statuses derived from the token. To retrieve a property from a given marker, use syntax as for a player, except swapping in marker for player : @(marker.Staggered.html) @(marker.blue.html) @(marker.sugar-plum.tag) If no property is supplied, Fetch assumes you are looking for the html associated with that marker, so these formations are functionally equivalent: @(marker.Staggered.html) @(marker.Staggered) A Note on URLs and HTML Some markers, like the colored circles, are accomplished using HTML and CSS only. There is no 'image' implemented from which to provide you a URL. That is when you want to use the html property for any presentation. Token Status Properties Statuses refer to token markers that have been assigned to a given token. They bear all of the properties of a marker, except that they also have other properties (like a value property) that make them quite flexible for reporting data from a token. Use any of the methods for identifying a token (selected, tracker, id, name, etc.), followed by the keyword status , the status to inquire about, and the property to return: @(selected.status.broken-skull.html) If you don't specify a property to return, Fetch will return the value property: @(selected.status.broken-skull) If there is a value connected to this status on the token, it will be returned to your command line. If there is no value, an empty string will be returned and no default value will be swapped in (the value is there, it just happens to be an empty string). If you only wish to test whether the token bears that status, use the is pseudo-property, instead (see below). See Default Values for more information on providing default values. is (pseudo-property) Fetch status returns offer a pseudo-property of being able to tell if that token has the given status ( is ). This would be the equivalent of asking "is the token staggered?": @(selected.status.Staggered.is) count (pseudo-property) Players can only assign one instance of a given status to a particular token, but Mod Scripts can apply multiple instances (see TokenMod documentation for a method of doing this). In other words, you can have a situation where a Mod Script has assigned multiple blue circles to the same token. If you need to know the number of these, use the count pseudo-property: @(selected.status.blue.count) ? (the 'which' switch) By default, a Fetch status retrieval looks for the first instance of that status on the token. The token pictured above has two blue circle statuses assigned to it, the first having a value of 2 and the second a value of 7. For that token, the following formation will return a value of 2: @(selected.status.blue) To designate a different instance to reference, use a question mark. The following will retrieve a value from the second blue circle (returning 7): @(selected.status.blue?2) Use the ?all selector to string together all the values from the instances of this status on this token. For the token with two blue circles (at 2 and 7), this would return 27: @(selected.status.blue?all) Use the ?all+ selector to total all values from the instances of this status on this token. For the same token, this would return 9: @(selected.status.blue?all+) Using is/count With ? When you have used a question mark to designate a particular instance of the status, you change how is and count behave. Since you have only designated a single instance of the status, count will always return either a 0 or a 1. @(selected.status.blue?2.count) There is only a single status that can be the second instance of the blue status marker, so if it is there, this will return 1. If it is missing, it will return 0. Similarly, the is pseudo-property will now refer specifically to the designated instance of the status. In other words, this formation essentially asks, "is the token marked staggered at least twice?": @(selected.status.Staggered?2.is) Pseudo Properties As mentioned, a pseudo-property is a property that isn't attached to the object by default, but which has only one potential value, so it can be assigned to a retrievable handle. These come in handy as ways to expand way you can use Fetch structures to retrieve data. There isn't anything specific about pseudo-properties that you need to know other than that there are more properties above/beyond what are typically available to a Roll20 object, so if you need a particular datapoint, check the property lists. It may already be there. Here are some specific examples of pseudo-properties: TOKEN PSEUDO-PROPERTY ======================================================= NORMAL: @(selected.represents) // returns: -M123456789abcdef PSEUDO: @(selected.represents_name) // returns: Bob the Bold
NORMAL: @(selected.page_id) // returns: -M0a3456789abcoog PSEUDO: @(selected.page_name) // returns: Fortress Keep
NORMAL: ...tracker info unavailable from token...
PSEUDO: @(selected.tracker) // returns the tracker initiative value for this token
PSEUDO: @(selected.tracker_offset) // returns the number of turns until this token is "up"
CHARACTER PSEUDO-PROPERTY ==================================================== NORMAL: @(Bob the Bold.char_controlledby) // returns: -Mjsa0vbn209as8sg PSEUDO: @(Bob the Bold.char_controlledby_name) // returns: FlapjackeryMcGee
Token Statuses as Pseudo-Properties Token Statuses are unavailable as Roll20 constructs to begin with, and so in a way are wholly made up of pseudo-properties. Being able to total all of the values for a given status marker (blue@2 + blue@7 = 9), or to chain them into a larger number (blue@2 + blue@7 = 27), or to detect if a given status is assigned to a token at all, or whether it is assigned some number of times, or to return the value of a particular instance of a given status marker... all of that gives you new ways to utilize status markers, especially if you consider using other metascripts (i.e., using APILogic you could effectively construct a command line that take actions based on conditions defined by the status: "if the token is marked 'staggered', take one action, otherwise take a different action"). Read more on token statuses in the section Token Status Properties. Read more about other metascripts at the ZeroFrame Meta Toolbox thread, or at the Metascript wiki article , this article on using metascripts , or this page of examples . Using the Tracker Using tracker syntax to designate a token (or, from there, a character), you don't have to return the current token in the turn order. You can refer to tokens in some offset from the current turn. The following construction would refer to the next-token-up after the current turn: @(tracker+1.ac) Similarly, this would refer to the token who acted 2 turns ago: @(tracker-2.ac) If the offset is more than the number of tokens in the turn order, the process loops until we arrive at the token being referred to. GMs Can Use Filters If you are a GM who has run combat that spanned across pages in your game, you know that your Turn Tracker contains entries for all of the tokens in combat, no matter what page they are on (players only see entries for the tokens on the page they, themselves, are viewing). Your offset values therefore might be different from what players would retrieve. To bridge this, Fetch offers 3 filters to the tracker syntax. Insert them, enclosed in brackets, in the tracker syntax prior to the offset. @(tracker[page].ac) @(tracker[ribbon]+1.hp) %(tracker[gm]-1.HealthReport) Page is the default if no filter is requested. Default Values One of the key benefits of a Fetch construction is that it does not break the chat parsing if the thing you have requested is not there. If you request a character attribute using Roll20 syntax and Roll20 doesn't find that attribute on the specified character, it will give you a message in the chat pane loudly announcing that fact. Using a Fetch construction, you can supply a default value and have that substituted in if the thing you are looking for doesn't exist. All Fetch constructions have a standard default of a zero-length string unless/until you provide something else, so if you don't get a return from your Fetch construction, this could be the reason. Default values can be inserted into any Fetch construction. Enclose the default in brackets, and place it directly before the closing paren (i.e., the last thing within the Fetch syntax): @(Bob the Hirsute.AxeJuggling[Untrained]) @(Sev the Fragrant.HygieneMod) @(selected.tracker)