Nesting macros in a dropdown query is a huge P.I.T.A., because of the Roll20 Order of Operations . Abilities are expanded (meaning the definition of the ability is placed in the formula anywhere that ability appears; e.g. %{character name|ability_name} becomes /r 1d4 ). Macros are expanded (e.g. #macro-name becomes /r 1d4 ). Attribute calls are resolved. (e.g. @{attribute_name} becomes 4 ) Steps 1-3 are repeated up to 99 levels deep, or there are no longer any expansions required. Roll queries are executed up to 99 levels deep (the player making the roll is asked to provide a value for each query, and that value is substituted in where the roll query appears in the formula). Html entities within roll queries are parsed once after each roll query (e.g. } becomes } , but } becomes } ) Inline rolls are executed, starting with the most deeply nested inline roll working upward. The overall result of the inline roll is substituted in place where it appeared in the formula. The remaining roll is executed : first, dice are rolled for any dice (e.g. 2d6 is rolled; including any special dice such as dropped or exploding), then the result of that roll is substituted into the formula. Mathematical functions like floor() and ceil() are executed. The entire remaining formula is evaluated , including observing proper Math Order of Operations (parentheses first, then multiplication/division, then addition/subtraction). Html entities/replacements are processed once more The message is sent to q Text Chat as well as the API sandbox . So when you have a basic query that looks like this (I'm super simplifying this): ?{Which Manoeuvre?|Attack,#Attack|Defend,#Defend} And your Manoeuvre macros are something like this: #Attack &{template|npcaction} {{rname=Attack}} {{description=This is the description of the attack you are making}} #Defend &{template|npcaction} {{rname=Defend}} {{description=This is the description of the defense you are making}} When you enter the initial query, Roll20 parses (replaces specific items) the macro calls, following the Order of Operations. So the initial basic query is changed before it is finally processed into: ?{Which Manoeuvre?|Attack,&{template|npcaction} {{rname=Attack}} {{description=This is the description of the attack you are making}}|Defend,&{template|npcaction} {{rname=Defend}} {{description=This is the description of the defense you are making}}} Now that everything that should be parsed has been parsed, it is then 'processed' as a command. And it 'breaks' because the initial query is bounded by specific characters: vertical pipes '|' , closing braces '}', and commas ','. When it sees a vertical pipe, it assumes that it separates the next query item; when it sees a comma it assumes it is the output for the query item; and when it sees a closing brace it assumes that is the end of the query. ?{Which Manoeuvre?|Attack,&{template |npcaction} The vertical pipe here becomes the second query item, because it doesn't recognize that there is a nested item within the query starting with another opening brace. So you have to replace all the complicating characters in the macro that is called within the query. Everything that is within the #Attack and #Defend cannot use a vertical pipe, comma, or closing brace. They would have to be replaced ('escaped') with html entity substitutions. Then it's further complicated if there are any calls or queries within those macros, and they'd have to be 'double escaped' to function.
