Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
This post has been closed. You can still view previous posts, but you can't post any new replies.

Roll Table Output as Data in Macro

1441535713

Edited 1441535805
Not a Pro user : /  so API is not an option at this time. Use a Roll Table to generate hit locations [HitLoc]. They output fine through a Macro #HitLocs ([[1t[HitLoc]]] with text-style inline output like "Chest". Ideally, I'd like to have the table output used in a Target operation to specify the value of the struck location and call the armor value off to subtract that from the damage die thus: @{target|<name>|#HitLocs|}; tried many methods and none work. Any suggestions, and has making the output values of a roll table operationalized been made if not?
1441546113
The Aaron
Roll20 Production Team
API Scripter
This is not possible without the API. See the Order of Operations:&nbsp; <a href="https://wiki.roll20.net/Dice_Reference#Order_of_Op" rel="nofollow">https://wiki.roll20.net/Dice_Reference#Order_of_Op</a>... Attribute references are expanded in step 1, rollable tables are rolled as part of step 6.&nbsp; I think there is a way to use the AI Buttons (doesn't require the API) to do this in a two step method, you might read the last few posts in general, I seem to remember it being discussed there.&nbsp;
1441616433

Edited 1441616466
Well, I guess my question to that answer would have to be: WHY? Abilities (the values of the abilities) are essentially CONSTANTS. Order of operations ought to be about determining the values of the variables that can be discovered and substituting those in first, since the constants don't change anyway. Furthermore, I'd like to note that the "Order of Operations" does NOT explicitly state where table-generated variables are taken (and it should). Resolving and substituting Roll Queries, and substituted variables, and Table Results ought to be the first steps in the order of operations because then these could be used to specify the Abilities (and their accompanying constant values) which are desired inside the Macros. Substituting the player-specified values for these items would not change anything else within the process of resolving rolls, and then there would be the added benefit to use the results from tables and queries to specify the Abilities wanted for later operations. There's no good reason I can perceive that makes it necessary to expand abilities prior to these other steps. Any DEV willing to step up promulgate the justification for this? Thanks.
1441632126
The Aaron
Roll20 Production Team
API Scripter
There are many systems which would be impossible to play on Roll20 without expanding attributes first. Here's some same rolls that would all be impossible without it: Stealth check [[ @{stealth_dice}d6 ]] Traits [[ @{importance}t[traits] ]] Feat of strength [[ (3+@{strength})d10&gt;7 ]] Its something of a chicken/egg problem.&nbsp; I can't speak to the reasons, but I'd be willing to bet there are more mechanics supported by the current implementation than the alternative one. Roll20 endeavors to be as system agnostic as possible.&nbsp; Certainly, being able to expand attributes to build other attribute or table or character names would be a nice feature. I'm pretty sure there is a suggestion in the suggestions and ideas forum for this already, which you might like to take a look at.&nbsp;
1441632234
The Aaron
Roll20 Production Team
API Scripter
Regarding when Rollable Tables are expanded, they are rolled along with dice. I'll see if I can make that clearer in the Wiki.&nbsp;
Dean C. said: Any suggestions, and has making the output values of a roll table operationalized been made if not? I'm going to need to do something similar to this for WFRP damage calculations, so i was interested in the answer. But I just wonder why you feel it necessary to use the output from the hit location table as the input to the damage location data. &nbsp; In WFRP the same dice roll that determines the hit location also identifies it for armour and wounds. &nbsp;So, for example a roll of 56 to 80 on 1D100 equals a hit to the body. &nbsp;Could that roll not be used to reference both the hit location table to return the text "Chest", and also used to query the chest attribute of the characters sheet to determine wounds and armour. &nbsp;Or can't you use the same dice roll to reference more than one thing.
Hi&nbsp; Dean C. - Since your original question has been answered, I will be closing this thread. If you would like to create a suggestion thread based on your post you are welcome to, just head over to&nbsp; that forum , read our&nbsp; Guidelines , and start a new thread if necessary, making sure to search for your topic first to ensure you do not create something that has already been suggested. Have a great day!