David M. said: If using 5e, you could assign the default token size with something like this: --size|@{Kobold|token_size} However, you won't be able to dynamically generate this for any given (e.g. queried, rolled) character name***, since attribute values get expanded before being passed to the api. Can only hardcode like I have in the example. ***If timmaugh is lurking, there is a decent chance that some meta-script magic can make this dynamic! Yep, there is! Although my lurksomeness wasn't very lurksome this weekend... but I'm here now. =D I can think of a couple ways to do it with metascripts. The basic concept we're trying to solve is that Daniel wants to have a random monster derived from his table, and then use the particular parameters of that monster to populate the Spawn commands. Like David said, the Roll20 order of operations will resolve a query before the roll against the table, so we need to stack up our steps on the backside of the roll. That means we need a way to extract the information from the roll. ZeroFrame can help with that: [[1t[Monsters]]].value Any inline roll appended with .value will extract the value in that position of the command line. It works for re-using rolls, too: $[[0]].value That much will be required for any of the below options. Option 1 - Fetch & ZeroFrame If you are playing in 5E (to make use of the token_size attribute David mentioned), or you want to add that attribute to your monster character sheets, you can use Fetch. Assuming your rollable table returns the name of the monster you wish to spawn: @($[[0]].value.token_size[1]) ZeroFrame extracts the value of the roll first, leaving a valid Fetch call when it does. As long as your rollable table of monsters returned the name of a monster that matched your a character sheet, and each of those characters had an attribute named "token_size" you could use this method. That means you could expand it beyond 5E, but you'd have to manually add the field to each monster character sheet. If Fetch doesn't find the attribute you ask for, it returns the default value you provide (in the above example, I supplied 1 as the default). Working Example: !Spawn {{ {&select SB} --name|[[1t[Monsters]]].value --size|@($[[0]].value.token_size[1]) --qty|[[1d3]] --placement|grid 3 --offset|[[(2*(1d2-1)-1)*1d6]],[[(2*(1d2-1)-1)*1d4]] }} Option 2 - Fetch & ZeroFrame Another option using Fetch would be to have a single character sheet that housed all of the token sizes you might need, and have them named according to a pattern. If the character were named "GameData", and the attributes were named token_size_Kobold , token_size_Calamari , etc., you could do: @(GameData.token_size_$[[0]].value[1]) Now you have a single place to store all of the sizes you need, and you don't have to store an individual size for each character (if all of the humans are going to be the same size, just have a single entry). Working Example: !Spawn {{ {&select SB} --name|[[1t[Monsters]]].value --size|@(GameData.token_size_$[[0]].value[1]) --qty|[[1d3]] --placement|grid 3 --offset|[[(2*(1d2-1)-1)*1d6]],[[(2*(1d2-1)-1)*1d4]] }} Option 3 - Muler Muler sets up character abilities to be tables of information. This would be much like Option 2, above, except that instead of a bunch of different attributes on a character, it would be a series of entries in the same ability. The same "GameData" character can work for this; it can serve multiple purposes (if you had a reason to use the Option 2 method for one problem, you could still use it as a Mule character for Muler). On that character, if you name an ability TokenSizes, and you structure the contents of that ability like this: Human=1 Kobold=2 Calamari=3 ...(making the sizes appropriate to your system), then you could do this in your Spawn command: get.GameData.TokenSizes.$[[0]].value/get That would retrieve the size for the monster that resulted from rolling against your table. Working Example: !Spawn {{ {&select SB} {& mule GameData.TokenSizes} --name|[[1t[Monsters]]].value --size|get.GameData.TokenSizes.$[[0]].value/get --qty|[[1d3]] --placement|grid 3 --offset|[[(2*(1d2-1)-1)*1d6]],[[(2*(1d2-1)-1)*1d4]] }} Note: There is an additional bit of syntax (included on the first line) to tell Muler to load the Mule that holds the variables you want to retrieve. In this case, we needed to return data from the TokenSizes Mule, so we told it to load that one. Note, the second: While this option might seem less intuitive at the beginning, having a little more syntax in the command line and having all of the token size information in a single ability rather than individual attributes, it begins to pay for itself if you have multiple pieces of information you want to return for a given monster. To illustrate that, imagine wanting to return 4 pieces of information about a monster that aren't tracked on the normal character sheet for that monster. Now imagine tracking those 4 pieces of information for 9 monsters. Even tracking all of that on a single character sheet can get painful if they each are housed in different attributes. Instead, Muler gives you the ability to have all of the information together... you could have 9 mules (monsters) with 4 pieces of information, or you could have 4 mules (information characteristics) that list an entry for each of 9 monsters. While there might not be multiple datapoints you need for a given monster just for the Spawn command, if you begin to spread into ScriptCards to launch things like Spawn, TokenMod, etc., then you may very well arrive at multiple pieces of information you need only *after* you determine what kind of monster you are dealing with. That's where this method can really shine.
