OK... couple of things... It looks like you want the house to roll 2 Red dice, and the player to roll 1 blue. The difference in the Red dice is the range that the blue die has to be between for the player to win... is that correct? And for a winning throw, any of your odds equations will work, but the Difference equation is definitely the easiest. If that is all correct, let me quickly answer your questions (and what was going wrong in that roll) before I give the working version: Roll20 takes an inline roll like this: [[1d20]] ...and parses it to derive the value (and some other data) which gets added to the message object in code. In place of this verbiage in the command line, Roll20 leaves behind a "roll marker" -- which is just a new index number in a formation like: $[[0]] or $[[1]] or $[[2]] etc. Rolls are (roughly) resolved left to right, inside to out. RainbowEncoder has a fuller write-up on their understanding of how indices are assigned, but if you think about a parser operating left to right and look for which set of closing double brackets is encountered first, you'll be able to figure out which roll is referenced by which index. That means that a roll like this: [[ [[1d6]] - [[1d6]] ]] Has indices like this: 0 1 2 [[ [[1d6]] - [[1d6]] ]] When that is parsed out of the command line, what will be left behind is the OUTER-MOST roll, or $[[2]]. The other two rolls ( $[[0]] and $[[1]] ) are available, as well, but the roll markers for those are not left behind. Once you get past assigning the roll indices, you can't (natively) do math with the rolls. That is, you can't use a roll marker like $[[0]] within another inline roll: ... THIS DOESN'T WORK ... [[1d20]] [[ $[[0]] + 1d10]] The parser doesn't know where to go to get the information for that roll's value. The roll marker is really there for formatting purposes (when a message hits the chat window and gets the hover roll tip), and for mod scripts to know where to get the value for the roll. ZeroFrame uses some tricks to repeatedly engage the Roll20 parser. It's basically a loop: Roll20 detects rolls and creates roll markers ZeroFrame detects "deferral" characters and removes one level of them, exposing NEW roll constructions, and sends the message back to Roll20 Roll20 detects new rolls and creates roll markers etc. The deferral character is a backslash, or (for the opening double brackets of an inline roll, specifically), a right-bracket following all of the deferring backslashes. One backslash = one pass of the loop. This means that new constructions can be delayed a precise number of loops, depending on how long we have to wait. For the above example (the one that didn't work): [[1d20]] [[ $[[0]] + 1d10]] ...the second roll only has to wait for ZeroFrame to be able to find the value of the roll. That means we have a loop where Roll20 parses the rolls it sees to arrive at the roll markers. During that loop, ZeroFrame has a chance to get the value of the $[[0]] roll and supply it. That means the second roll could be evaluated during the second loop, so we only need 1 level of deferral: [[1d20]] [\][\] $[[0]] + 1d10 \] \] Of course, to engage the metascripts, it has to be part of a bangsy message (starting with a ! ). To see the results in the game, you'll need to include a {&simple} tag: ! [[1d20]] [\][\] $[[0]] + 1d10 \] \] {&simple} If you were to add another roll (a third roll) that required the results of that second roll, that would require 2 levels of deferral, since it has to wait until the value of the second loop rolls becomes available. !No deferral: [[1d20]] Single Deferral: [\][\] $[[0]] + 1d10 \]\] Double Deferral: [\\][\\]$[\\][\\]2\\]\\] + [[1d10]] \\]\\]{&simple} ZeroFrame will auto-replace the roll marker with the roll value if it detects that it is about to send a roll equation to Roll20 which includes a roll marker as part of a new inline roll... that's why the above will now work. In any case, this complicates roll index assignment. Here is the same command line with indices attached to the rolls: 0 2 * 1 3
!No deferral: [[1d20]] Single Deferral: [\][\] $[[0]] + 1d10 \]\] Double Deferral: [\\][\\]$[\\][\\]2\\]\\] + [[1d10]] \\]\\]{&simple} Roll indices are assigned as Roll20 encounters the closing double brackets, so rolls that are deferred for a future loop ARE NOT ENCOUNTERED immediately. Each loop continues to count up. Two rolls are found in the first pass, getting indices 0 and 1. During the second loop, one level of deferrals have been removed, exposing a new roll that gets index 2. During the third loop, a new roll is exposed, getting the index of 3. Note that the special closure marked with an asterisk is not a new roll, and so does not get a new index. When the deferral characters are finally removed and the core syntax is exposed, it is an existing roll marker: $[[2]] TL;DR Solution With all of that explanation, here is the version that will work for you: !&{template:default} {{name=Dice Roulette: Straight}} {{Dice=You chose ?{Dice|6|8|10|12|20} sided dice.}} {{Red 1=[[1d?{Dice}]]}} {{Red 2=[[1d?{Dice}]]}} {{Difference=[\][\] abs($[[0]] - $[[1]]) \]\]}} {{Payout= [\\][\\]?{Dice} - $[\\][\\]2\\]\\] + 1\\]\\].value:1}} {&simple} You didn't need the abs() function in the last roll since you were referring to a roll where that had already been applied. You needed to double-defer the last roll since it was waiting on the Difference roll which was, itself, already deferred once. Your payout formula for using the Difference equation was incorrect -- it was wanting to pay 8:1 for situations where the Red Dice were equal, and an extra +1 for all other cases. I reduced it from +2 in the equation to +1, and things work. Here are a couple example outputs: My understanding is that you want this in the chat output, and then the player can roll their die on the VTT and read the number and manually compare to the data in the panel. If you instead want the player's die to be included in the output panel, you can add it, of course. =D
