There are instructions on the threads for those scripts, but it might help to cut to the chase of what you need to know: Create a character, and give control rights to everyone who will need to access the mule table. Create an ability called "DifficultyTable" and paste in the table from my previous post. Save/close the ability To make a mule available to a roll, use the {& mule...} syntax {& mule DifficultyTable} => loads the first ability found called DifficultyTable (from all characters you control) {& mule TableMule.DifficultyTable} => loads the DifficultyTable mule from a character named "TableMule" {& mule DifficultyTable, Chronos.TimeModifier} => loads first "DifficultyTable" and the "TimeModifier" mule from character "Chronos" Then to get a value from it, you use the get syntax get.variable/get => if the variable is uniquely named among all LOADED mules (for this call), you can just reference the variable get.mule.variable/get => if multiple loaded mules might contain the same variable name, you can get it from a specific mule If you want to add a new variable to the mule, just add a new line setting the variable name equal to the inline roll that should result. For instance, here are two more variables: You just wanna die now?=[[8d6]] Caskets don't fill themselves=[[9d6]] Add these to the roll query by using the variable name. For roll queries, pipe characters separate options, commas separate label vs returned value... so it might be easier to name your variables something like "wannadie" and "caskets", and then reference them in the roll query by using your full text as the value the player would see (i.e., "You just wanna die now?") and returning the "wannadie". I say "return" because that's how you should think of it. Roll20 parses the line to remove the roll query and leave the result in that place in the command line. For us, that means putting the result of the query into the variable position of a get statement: get.<roll query result>/get These metascripts (like Muler) are working on (and changing) your command line. This can happen before it is sent to another script, or before your message is sent to the chat interface. In your case, you need the finished command line to be processed through the chat, so we include the {&simple} construct. So although we start with an exclamation point (to initiate the API processing the message), when all of that work is done, we want to dump the finished line out to the chat. In the example from my previous post, that was just a roll result... but it could be a part of a roll template, too: !&{template:default}{{name=Difficulty Check}}{{Result=get.?{What difficulty is this action?|Easy|Average|Hard|Difficult|Very Hard|Staggeringly Difficult|Nigh Impossible|What the hell}/get}} {& simple} {& mule DifficultyTable}
