Unfortunately, that is correct. Advanced Usage for Roll Queries said: On the flip side, if the assigned value of a nested Attribute, Ability
or Macro contains any problematic characters, that nested item will
cause its Roll Query to break as surely as if that item's assigned value
was inserted directly into its Roll Query in place of its call. So, if
the assigned value of your nested Attribute, Ability or Macro does
contain problematic characters, consider replacing any or all instances
of that nested item's call with that item's assigned value, and then
subjecting that assigned value to the above character replacements. As long as your macros contain one or more closing braces (e.g. from Roll Template syntax), commas or vertical bars, they will break a Roll Query that they are nested within. If you replace these "problematic characters" within each individual macro with HTML entities, you will be able to nest their calls within a Roll Query, but those macros are most likely now broken as individuals. Essentially, one must decide between using multiple macros individually or nesting their assigned values within a single Roll Query. Troubleshooting (Nesting Macros) said: Due to the order of operations ,
macro calls nested within Roll Queries are fully expanded before the
query is executed. This means that if a macro nested within a Roll Query
contains any problematic characters, which conflict with Roll Query
syntax, that nested macro may cause the Roll Query to break. If this is
the case, it may be necessary to either remove or replace problematic
characters within that nested macro with HTML entities (see: Advanced Usage for Roll Queries ). Note that macros which contain HTML entities may no longer function autonomously and must be saved as Abilities .
