As for your first question... why the text isn't showing up... Your secondary text isn't showing up because it is, itself, enclosed in the outer roll: [[ ... [[ ... ]] derp ]] As currently constructed, you don't need the outer roll brackets... you aren't doing any more math. This will work: ?{Pick one|Zombie,[[1d20]] derp|Blurp,[[1d20]] derpalot|Borzoi,[[1d20]] derpatology} And since the rolls are all the same, they could really be moved outside the query, with only the color text included in the roll query... but I'm guessing that your query is currently constructed just to test things (using dummy/duplicate rolls), and you'll eventually have different roll values for each entry. If that's the case, then you would need to have them included within the query as it is currently constructed... so I won't both with moving them for now. As for your second question... using the choice of one query to drive multiple different datapoints... You can do this a couple of ways, but without scripts they would involve a geometric proliferation of rollable tables, or a multiplicative output of entries in a single table. Neither of those is really manageable after a few generations of data expansion. With scripts, everything becomes easier. A lot of people might favor a setup that uses a script called Recursive Tables, but for something like what you want to do my preference would be for the Metascript Toolbox (and not just because I wrote it!). =D Using the Metascript Toolbox, you could set things up in different rollable tables or in a single data store (a mule ability). I'm not 100% sure of how your undead query choice is supposed to drive your other data, so... generally speaking... The rollable table solution would have you coordinate item weights (chance of occurrence) and position within the table to match retrieval. For instance, if everything was a 1:1 return, you would give everything in TableA a weight of "1", and everything in TableB a weight of "1". Then you would make sure that the order of items matched: TableA TableB ========== ========== Dog canine Cat feline Pig porcine Horse equine Bear ursine Cow bovine Then you could either pick or generate a number (random from the total "weight" of the table -- retrievable via a metascript), and use that number to return *that item index* from the other table. That is, the total weight (as depicted) of TableA is 6. If your was a 4, you'd get "Horse" from TableA and "equine" from TableB. If you expanded TableA to include breeds of those animals (instead of "Dog" you had "German Shepherd", "Golden Retriever", and "Creature from Another Planet Claiming Dog DNA"), then the entry for "canine" in TableB would have to have the appropriate weight (in this case, 3) to cover that number of breeds. Then the entry for "feline" would pick up from that point in the count of indices, etc. The mule ability version would function very similar, except that instead of a few tables you would have a few abilities on a mule character. The structure of the data would be roughly similar, this time with the spans of values that index each item in the mule placed on the left side of an equal sign, and the data to be returned on the right: 1-3=Dog 4-6=Cat 7=Pig 8-9=Horse 10=Bear >11=Cow I moved things off a "1 unit weight" standard to show the basic structure of the spans of values (ie, anything between/including a 1 and a 3 would give you "Dog", so that's effectively a weight of "3"). After that, the mechanic is the same as the table solution... produce your number and read from the appropriate mules. The syntax for this solution would be different, of course, but right now I'm just describing the approach so you can decide what seems easier for you to work with.
