Not in the way you would want to customize and format various parts. The metascript toolbox (ZeroFrame, SelectManager, Plugger, Muler, APILogic, MathOps,etc.) gives one more level of information retrieval that you can use for other messages. Typically you have Roll20 retrieval (things like @{selected...} or @{target...} or @{character name...}), and then you have processes hard-coded into a script. That is the order they go in. Metascripts get in the middle of that*. Where most scripts want to own the message (you are sending a message to PowerCards; or you are sending a message to TokenMod; or you are sending a message to ChatSetAttr, etc.), metascripts give you the opportunity to detect particular requests within the text of the message. Since they run before the destination script (e.g., running before PowerCards), they alter the command line that PC will ultimately see. That's why your PowerCard can get quite simple - by the time it sees the command line for any particular message, Muler will have changed it to provide the extra text content. The metascript toolbox can provide these line-changes to almost any script*, or they can be used to retrieve information that is ultimately just output to chat directly, using built in Roll20 constructs (if you have ZeroFrame installed). That's what I was doing using the default template in my example. That template is available in any game no matter what system you are running, but you could change it to be a particular template from a particular character sheet. Those other templates will have other formatting. If you want to use those, you'd start with an exclamation point (to trigger the API), then continue with the message content as you would want it to appear in chat (using a roll template, for example), before ultimately including a {&simple} tag. (You'll see this tag in my example). That ultimately tells ZeroFrame to output the message content -- in whatever state it's been left -- at the end of the metascript processing (instead of letting it pass on to other scripts). That lets us use metascript constructs (like retrieving variables from a mule) in messages we only intend to hit the chat (instead of another script). So you CAN use the metascript constructs in different outputs that already have formatting (roll templates), or you can use them in other scripts that give you a more granular control over the look of the message. That's where I was suggesting ScriptCards, as I have not noticed the problem I was running into (where PowerCards wouldn't provide a tooltip for a roll you let Roll20 parse). You can look at the thread on working ScriptCard examples or the wiki examples to see some of the formatting you can achieve with those. * - one caveat about when metascripts work is that they don't HAVE to be installed prior to other scripts, for the most part . They use a trick to get themselves to the head of the queue of scripts waiting to handle any message. This works for 99% of scripts. PowerCards can be one that doesn't play nicely with metascripts. Completely by chance, it happens to use the same trick to get itself to the head of the queue; so if it happens to be installed first (and therefore processed first when your sandbox boots up), it will get in line BEFORE the metascripts. This can be corrected by removing and re-adding PowerCards after you have the metascripts in place, or by editing a line of the code of the script. I am reaching out to Kurt to see if he can submit a change to PowerCards to make it work with the metascript toolbox regardless of the installation order. For now, you may need to perform the remove-and-reinstall trick to get the order correct.
