Andrew R. said: Is there a MetaScriptToolbox work-around? Yes. Well, yes...ish. Yes and no. For the necessity of the xBox to interface with Beacon, there is no workaround. That's just the way things have to be because of the code required for those operations. But for the loss of the tokens selected when you use a targeting statement, there is a metascript workaround... within certain limitations. SelectManager tracks the tokens that are selected when a human-generated command is run (these messages can have selected tokens) so that if it later sees a script-generated message come through (these messages cannot have selected tokens), it can assign that package of tokens to the script-generated message. As an example, this crops up when one script calls another... for instance a ScriptCard command issuing a command to TokenMod. The ScriptCard message could potentially have selected tokens, but when it dispatches the TokenMod command, that new message will NOT have selected tokens. Why that explanation on how SM does what it does? Because when someone uses a targeting statement, that initial, human-generated message comes through with NO selected tokens, as The Aaron pointed out. That means there's nothing for SelectManager to track and/or restore. So, if we're going to work around that, we have to use SelectManager's {&select} tag and somehow refer to the tokens we want to select. This will introduce a set of selected tokens to the message. ONE token of however many we might have selected on the VTT board will be available to us this way... because even though the message won't have selected tokens, Roll20 WILL resolve @{selected|...thing...} references. So, for whatever token is selected "first" (as Roll20 sees it, which might not be the order you clicked on the tokens), we can resolve an @{selected|token_id} reference in a {&select} tag, like this: {&select @{selected|token_id} } But... that will only ever be one token. Also, for TokenMod, this construction doesn't get us very far, since we could have always used the --ids command of the TokenMod command line to instruct TM to operate on those tokens: !token-mod --ids @{selected|token_id} ... The Workaround Options If we want to operate on multiple tokens as if they were selected (or just want to take advantage of the fact that a destination script like TokenMod will operate on the selected tokens), we can use: selection criteria (as amended here ) store token IDs in an attribute ...to get the tokens we want. The idea would be that you can set up a "group" of tokens and select them via either criteria (in option 1) or by reference to the attribute storing the token ids (in option 2) when you use a command that also includes a targeting statement. The idea, here, would be to designate the group in an ad hoc fashion via one command, then refer to it in a target-syntax-using command via a {&select} tag. To be clear: you will need to send 2 commands. The first one will have tokens selected and, using one of the methods just mentioned, build a group out of them (explained below). The second message will use targeting (your existing command) and therefore will NOT have selected tokens, but SelectManager will restore the tokens to the message. You cannot compress these 2 steps into a single macro, since the inclusion of the targeting syntax mean there are no selected tokens to use in the group-building. Option 1: Criteria (Requires: MetascriptToolbox + TokenMod) Let's decide on a particular marker to use as the ad hoc group designation. I'll use "red". Knowing that when you want to run the TokenMod command (that includes a targeting statement) you will have already marked the selected tokens with "red", you would prepare your TokenMod command line, altering it to include the {&select} tag: {&select *, +*red} That means that, from now on, when you run that command, SelectManager will change the message object that reaches TokenMod to include the red-marked tokens as "selected", even if you have other tokens selected on the board and/or if you use a targeting statement (and, so, there are no selected tokens in the message). Now, in your game session, if you want to use that TokenMod command (with the targeting statement), you would need to mark the tokens with red. To do that, you would physically select them on the VTT (I know: this isn't ideal; however, it's what you're doing today if you were already relying on tokens being selected on the board, but which you've now lost because of a targeting statement). After selecting them, you'd run this command: !token-mod --set statusmarkers|red That will mark the selected tokens with the "red" marker. Now you can run your TokenMod-targeting command (altered to include the {&select} tag), and the message will still have tokens for TokenMod to act upon. If it were me (and just because the Roll20 interface can be touchy about selected tokens), I would have my "grouping" command set up like this: !{{ (^)!token-mod --set statusmarkers|-red {^&select *} /w gm [Group](!
!token-mod --set statusmarkers|red ) }} That will first clear the red marker from all tokens on this page, then prompt you with a chat button to run the second command, assigning the red marker to your selected tokens. (The button makes the second command be its own message, unaffected by the {&select} tag in the first command.) So you'd select the tokens you want to group/target... then run the above command... then click the button that appears in chat (to apply the red marker)... then click your TokenMod macro with the targeting statement. Overall, that's 2 more clicks than your current process. Option 2: Attribute (Requires: MetascriptToolbox + ChatSetAttr) Much like the previous option, this one requires you to run a command to build your group before you use that group in a {&select} tag in your existing TokenMod-targeting line. The difference for this one is that we're going to use ChatSetAttr and store that on a character sheet. I've created a character named "CampaignMule" where I can store different datapoints I might need for the game, but if you were only a player (instead of a gm) you could store the "TargetingGroup" attribute on your own sheet (simply adjust the following command to point at your character instead of CampaignMule). This time, as part of your setup, you would modify your TokenMod-targeting line (the command where you will ultimately need to use the {&select} tag) to look for tokens that are in this TargetingGroup attribute. In other words, add this to that command line: {&select @{CampaignMule|TargetingGroup} } Then, in your game session, if you want to build an ad hoc targeting group, you would select those tokens and then run this command: !{{ !setattr --name CampaignMule --TargetingGroup| --silent !forselected(^) setattr --name CampaignMule --TargetingGroup|{^&if "@^(CampaignMule.TargetingGroup) " != " "}@^(CampaignMule.TargetingGroup),{^&end}@^(selected.token_id) --silent {^&delay .1} }} That will first empty the contents of the attribute, then build, in the TrackingGroup attribute, a comma-delimited list of the selected tokens. That comma-delimited list, when used in the {&select} tag noted above, will produce the list of tokens you want to use as your "selected" tokens for the command where it is included.
