It looks like you're new here. If you want to get involved, click one of these buttons!
When using a lookup table, I'd like to be able to call another table (ie: Roll:[@blah]
), or use conditionals/expressions (ie: Roll:[when]{$prompt1}=blah[do]1d100[else]1d6[end]
or {if({$prompt1}=blah,'1d100','1d6')}
I have tried all of these, and the closest I can get is to pass a variable with the >> with
filter, which gets me Roll:{$1}
. This is useful, but those additional functions would be extra useful.
Keep up the great work, this is an amazing tool!
Comments
Rolls like 1d100 or 1d6 are very flexible. For example, here's putting a user prompt as a conditional to select which die to roll. Instead of specifying a die to roll, there is a conditional; if met, roll a d100; if false, roll a die corresponding to the user prompt input. It obviously errors if the user input is not a positive integer number.
Here's another quick idea. In this example, I've weighted table [@blah] so that the first choice show up 200x more frequent than the others, meaning it rolls 1d10+20, or 21 to 30. It should always come up "dagger", and it does. Change up that first choice in table [@blah] to "10" or "10+10" and see it come up only sword or only spear. Of course now you could make Blah a lookup or dictionary table and send a more complex call for it to choose dice. Also, you should be able to replace the "1" in 1d with an expression or table call which returns how many dice will be rolled.
And another little fun one that makes a bit more practical sense:
I get what you're saying, but that unfortunately is overlooking my mention of a Lookup-type table. I would like to modify the roll of a Lookup table on each separate access of that table. Your suggestion does not facilitate that, although it works just fine on a Weighted table, which is what you show for example.
Okay, your second post is more amenable for what I was needing. Basically, you're creating a table that defines the roll, and then simply passes that roll to the Lookup table without needing the Lookup table to have it's own Roll attribute. That will definitely work for my purposes.
As for the feature request, I would like to leave it standing until weighed-in by devs, as I believe that would be a simple way to add programmatic flexibility to the Lookup table type.