(I see you've worked a few things out... I started this post earlier, so I'll go ahead and share it anyway in case it helps) First off... awesome. It's working. Second... about those backslashes... I should say before I begin that there is a difference between a backslash and a forward slash. A forward slash (for metascript syntax) simply denotes the end of a construction. So, a Muler set statement might look like: set. ... /set Or a Plugger statement might look like: {&eval} ... {&/eval} Those are separate from the backslashes. So, to understand those... The trick that (I think) keeps more people from using the metascripts more is understanding the timing of them. Metascripts happen after initial Roll20 parsing (roll queries, inline rolls, attribute retrieval, etc.), but before other/standard scripts. (For a discussion of this, go to this Roll20 Discord link, where I explained things in more detail.) ZeroFrame, one of the metascripts in the toolbox, organizes the others into an order that works for 99% of messages (and it allows for a way to change the order, as necessary). SelectManager runs before Fetch... APILogic is the last to run... you can see the order if you run: !0 At the end of each script having a chance at the message, ZeroFrame detects if anything was changed -- if any metascript did any work, like Fetch returning something from a character. If something was changed, then new metascript constructions might have been introduced... a muled variable might have been added to the command line that also included a Fetch statement, so we need to give Fetch a chance to resolve that construction. That's why, if ZeroFrame detects that anything was changed, it will run the series of scripts again. It first exposes the command line to the Roll20 parsers (resolving inline rolls, character attribute references, etc. -- everything but @{select} references and roll queries), then it starts down the series of metascripts, again. We call this the "loop". Since some formations won't be able to resolve until we've gone a loop or two deep in our processing, ZeroFrame offers a way to "hide" text constructions: the backslash. At the end of each loop where work was done to the message, a backslash is removed and the loop is run again. That makes it so that if we need to use Fetch to reference some math that we do in the first loop (and store it somewhere), we can hide the Fetch construction using a backslash: @\(selected.hp) A single backslash represents one loop cycle of deferring. We need as many backslashes as we have loops before that piece of information is available. An example: Inline rolls happen before metascripts, so if we need to retrieve a piece of information that isn't available through normal Roll20 syntax (maybe a token's "top" property), we have to get it with a Fetch construction. That means that the inline roll has to be deferred so that it doesn't run with the initial Roll20 parsing, but is only discovered after the first loop. If we then need to use the result of that roll in a separate Plugger operation, that operation has to wait until the roll is available, so it has to also be deferred for that first loop. If something else is dependent on the Plugger operation (and it would occur *later* in the order of metascripts), it will have to be deferred until after the second loop... etc. Make sense so far? Because it gets a little more complex before we're done. With a message like forselected (which dispatches a new command for each selected token) or a ZeroFrame batch statement (a bunch of commands batched up between braces: !{{ ...command 1... ...command 2... ...etc... }} ...), we have a single, top level message (call it the parent message) followed by multiple secondary messages (call them children messages). In fact, if you have a forselected command in a ZeroFrame batch (like we did for you), you actually have a "grandparent" message (the original batch set message), followed by a parent message (the message that ZeroFrame dispatches and is picked up by forselected), followed by children messages (the messages dispatched by forselected for each selected token). Each one of these messages gets its own metascript loop series... looping until ZeroFrame detects that no further meta-work was done to them. Therefore, if a metascript construction is present in the command line of the parent message (or grandparent message, in your case), it will pass through the loops of the parent message's metascript cycle... which means that it will also go through the undeferring (the removing of backslashes at the end of every loop). So if, as an example, we know that an embedded command in a batch set has to wait until the second loop of its own cycle to resolve, but we also know that the parent message has some meta-work going on, then the parent loop will already trigger one deferral. That means that the formations that need to be deferred in the embedded command will need 1 deferral for each of the parent message loops, and another 1 deferral for its own loop. You can see this in your command line, right at the top. !{{ !set.MuleCharacter.GroupCheckResults.Morale = 0/set Your command is a batch, where the first command (the first dispatched message) is a Muler set statement (to reset the variable we will eventually report out). That means that we're doing work in the top level message... so we have to pay attention to things that are a part of other dispatched messages which need to happen in a specific loop of *that* message. You can see this in the forselected line, which comes next in the batch. Here is just the beginning of the line, where we establish a pair of variables: !forselected(^) {^&global ([CheckTarget]?{Target|0}) ([ChkRolld20] [^[^1d20^]^].value)} {^\\\&global ([CheckRoll][^\\][^\\]ChkRolld20 + 0*^(selected.npcaction.$0.attack_tohit) + @^(selected.bar3)^\\]^\\])} When the full message goes through the metascript loop, one loop is required to finish the metascript constructions in the first line. That means that after that loop finishes (and ZeroFrame can get around to dispatching the forselected line), it will have removed one backslash from every series of backslashes. The forselected line excerpt will now look like this (note I am going to substitute a "10" as the target number, since the query would have resolved by this point): !forselected(^) {^&global ([CheckTarget]10) ([ChkRolld20] [^[^1d20^]^].value)} {^\\&global ([CheckRoll][^\][^\]ChkRolld20 + 0*^(selected.npcaction.$0.attack_tohit) + @^(selected.bar3)^\]^\])} Now, one more thing to realize: forselected offers a way to declare its OWN deferral character, within the parentheses that follow the script handle. I've used a caret because I know I don't need that character for the rest of the line that will be dispatched for each token. So when forselected dispatches this command line for each token, those carets will be removed, and the line that will be sent for each token will start like this: {&global ([CheckTarget]10) ([ChkRolld20] [[1d20]].value)} {\\&global ([CheckRoll][\][\]ChkRolld20 + 0*(selected.npcaction.$0.attack_tohit) + @(selected.bar3)\]\])} You can see how that now exposes Fetch constructions (the @(selected.bar3) reference), as well as the {&global... } variable declaration. That means, when each of these messages hit their own metascript loop cycle, there will be work done in the initial pass, so a new loop will be triggered. That will remove another backslash (and, for inline rolls that are at a single backslash, it will replace [\] with [ ), exposing inline rolls. The above snippet will now read (where the 1d20 resulted in an 8 and was substituted in for the ChkRolld20 variable, the tohit number was a 2, and the bar3 value was 12): {\&global ([CheckRoll][[8 + 02 + 12]])} You can see that we've no exposed an inline roll, which will get caught by the Roll20 parsers as the next loop begins. Coupled with removing the last backslash, and we have a {&global} variable declaration that will be detected (no more deferrals breaking up the text pattern), and it will be assigned to the result of the roll. Now you can take that to the rest of the roll... where you see anything that was waiting on the CheckRoll global variable, that construction will have to have at least as many deferrals as what the {&global} tag started with. Since global-variable replacements happen at the top of the loop, everything else in the metascript loop comes after them and shouldn't have to wait for them (maybe something else, but not them, anymore). That's what you need to understand about the backslashes, but as long as we're on the topic of deferrals, I should mention that ZeroFrame batching construction comes with 2 potential places to declare deferral text (since a ZeroFrame batch is going to dispatch child messages, you might need to preserve a construction until after the parent-message processing has finished, same as for a forselected message). The syntax for batch deferrals is the same as it is for forselected (enclosing it in parentheses). You can declare it for the entirety of the batched set of commands by following the opening braces: !{{ (^) ... }} And/or you can declare deferral characters for an individual line by including it as the first text on that line, even before an exclamation point if the line would begin with one: !{{ (~)!token-mod --set ... }} You can see one of these line-deferral declarations on the last line in the batch, where it launches the template: !{{ ... (^){^&template:default}({)name=... }} Anyway... that's the explanation. Hit me up if you have any more questions!
