resolving chained macros one at a time

Hi is it possible to chain macros in a way that the first macro fully resolves (and displays the result) before the second one is called? Specific use case: first macro queries an attribute value, the second macro does something with that value and displays it. When I run den separately, it works fine. macro1 "query for value - change the value accordingly - display result" macro2 "take the value, change it according to new query - display result". So if the information output from macro1 is relevant for choosing options for macro2, I can't call them with a single button "#macro1 #macro2". And I noticed that in that case I get queried for macro2 before macro1 is resolved. What I need would be  #macro1 !wait for macro1 to resolve #macro2 I found a delay script, but that only delays the display of the result, not the actual execution. Anyone any ideas? Thanks in advance! PS: I checked for problems caused by nesting "}" and there should not be any

There's no way for a command to wait for the resolution of another -- they just don't have that kind of awareness of another command being processed. The whole message is processed in one go and the individual commands are dispatched essentially one after the other.  However, there is a delay command in the Metascript Toolbox that might be able to help. The {&delay} tag takes a numeric value for the number of seconds (or fractional seconds) to wait before dispatching the command. In this way, we aren't delaying for the return of the first message/command, we're waiting a fixed amount of time, figuring that in that window the first command will have had time to resolve. So  you would just have to pick a value for the delay length that allows for the resolution of the first macro. Here is a version that waits .3 seconds: #macro1 #macro2  {&delay .3} ===== IMPORTANT SETUP CAVEAT 1 ===== The {&delay} tag is a part of script processing, which means that the command to which it is added (here, #macro2) must be a bangsy message (starting with a "!"). The above example assumes that the contents of #macro2 begin with a bang. If, instead, it is just a normal "send this to chat" report-style message, then you would need a little more verbiage. First, start with a "!", and then include the {&simple} tag somewhere in the command: #macro1 !#macro2 {&delay .3} {&simple} ===== IMPORTANT SETUP CAVEAT 2 ===== When Roll20 processes the commands in your message, a certain order of operations gets applied that includes expanding attributes, abilities, and macros up to 99 times deep (so if a macro contains a reference to an attribute, the macro will be expanded in the first pass, exposing the call to the attribute; that call to the attribute will be resolved in the second pass, etc.). ALL of that happens before scripts get the message. That means that in order for the second macro to report the value from an attribute that your first macro has changed, it CANNOT resolve that attribute until AFTER the first macro has finished. If it resolves during Roll20 parsing, it will obtain the preliminary, pre-change value, and hold on to it in the command line even as the first macro is changing that value. To get around this, you have to resolve the attribute call after Roll20 parsing, which means having a script do it for you. The MetascriptToolbox has a script that will do that, right in your command line (Fetch). Making references in your macro2 follow Fetch syntax is mostly straightforward for attributes. For instance: @{selected|ac} ...would become: @(selected|ac) ...or... @(selected.ac) As long as you use the parentheses instead of the braces, it works with the pipe or the period. I like to use the period because it's a quicker way to clue my eye in to the fact that this is a Fetch construction, not a Roll20 construction (the difference between braces and parentheses, visually, sometimes takes a minute to focus and decide what I'm seeing). YMMV, though. CONVERTING REFERENCES LIKE THIS TO FETCH CONSTRUCTIONS CAN REQUIRE OTHER CHANGES... for instance, if the-reference-that-was-an-attribute-but-is-now-a-Fetch-construction was within an inline roll, that roll will have to be deferred. That's a larger subject/explanation that maybe isn't necessary in this case, so I'll leave off for now and just say: i f you still are having trouble converting your second macro, post the contents and I will lend a hand.

Thank you very much for your help! That means that in order for the second macro to report the value from an attribute that your first macro has changed, it CANNOT resolve that attribute until AFTER the first macro has finished. That is exactly my problem. I never worked with the meta toolbox or fetch before. I changed the calls in macro2 to this style: @(selected.ac). Now the combined macro still works as before with the same problem, but when I run macro2 on its own it has a problem (does not display any output) if the-reference-that-was-an-attribute-but-is-now-a-Fetch-construction was within an inline roll, that roll will have to be deferred. I would assume that this ^ causes an issue. Since I have no clue how to do that, I will try to read up on it. Or can you suggest something? Ill post my macros here in case reading the full code helps with that. macro1 !setattr --charid -OeY7LIhzE43tP8BmGQW --DCVariable|?{DC Reached|DC 10, 1|DC15, 2|DC 20, 3} macro2 !rt[Delimiter:BR] &{template:default} {{Foraging Plants}}{{You Found =[[[[@(VariableStorage.DCVariable)]]t[[[[[?{Biome|Arctic, 1|Blightshore, 0|Coast, 0|Desert, 0|Feywild, 0|Forest, 0|Grasslands, 0|Hill, 0|Mountain, 0|Savannah, 0|Swamp, 0|Urban, 0|Underground, 0|Volcanos, 0}]][[@(VariableStorage.DCVariable)]]]]]]]}} combined #macro1 #macro2 {&delay .3} The {&delay .3} causes a delay, but the result is unchanged. The value in macro1 gets changed AFTER macro2 is executed Thank you again!

Yep... so the Fetch construction is in an inline roll in your second macro. If you really want to understand metascripts and deferrals (and have an hour to kill), I'd suggest this video I posted to YouTube. In any case, looking at your second macro just with an eye toward deferrals... I would change it to be: !rt[Delimiter:BR] &{template:default} {{Foraging Plants}}{{You Found =[\[\[\[\@(VariableStorage.DCVariable)\]\]t[\[\[\[\[\?{Biome|Arctic, 1|Blightshore, 0|Coast, 0|Desert, 0|Feywild, 0|Forest, 0|Grasslands, 0|Hill, 0|Mountain, 0|Savannah, 0|Swamp, 0Urban, 0|Underground, 0|Volcanos, 0}\]\][\[\@(VariableStorage.DCVariable)\]\]\]\]\]\]\] }} That *should* make those rolls defer until Fetch has a chance to resolve. Looking further... Now, with an eye toward "do you need all of that?"... I'm not sure you need the 2 inline rolls that are *within* the table designation portion of the inline roll referencing the rollable table. It *looks* like you're just getting a number from the DCVariable, and you're prepending it with either a 0 or a 1 (referencing a specific table for the Arctic biome which gets the 1), but making sure that you're still able to get a number. So I think you're referencing rollable tables that have a number as a name? If so, I think you can get that with just a single inline roll: [\[\?{Biome|Arctic, 1|Blightshore, 0|Coast, 0|Desert, 0|Feywild, 0|Forest, 0|Grasslands, 0|Hill, 0|Mountain, 0|Savannah, 0|Swamp, 0Urban, 0|Underground, 0|Volcanos, 0}@(VariableStorage.DCVariable)\]\] Also, I get that you might have modified/simplified your query that is a part of this macro, but if every other biome besides the Arctic really gets a "0", you could simplify it down to: ?{Biome|Arctic, 1|Other, 0} Meaning your potential command could simplify down to... !rt[Delimiter:BR] &{template:default} {{Foraging Plants}}{{You Found =[\[\[\[\@(VariableStorage.DCVariable)\]\]t[\[\[\?{Biome|Arctic, 1|Other, 0}@(VariableStorage.DCVariable)\]\]\]\]\] }} But, of course, I'm operating from standpoint where I don't have the full infrastructure of your game spun up where I can test it. I'm just saying this is where it looks like you can get some efficiency (if only in verbiage!).

If that command works and .3 is not enough of a delay, I would suggest upping it to maybe .6. If THAT still doesn't work, post back. There is another way we can force things to slow down.

I followed your advice, but nothing worked. Checked the API Sandbox and found out: I'm getting an error now and don't know where it comes from....even when using my old macros that worked (the issue with the value being resolved aside) SyntaxError: Expected "(", ".", "[", "abs(", "ceil(", "d", "floor(", "round(", "t", "{", [ |\t], [+|\-] or [0-9] but "\\" found. undefined MetaScripToolbox installed a ton of secondary scripts, and it does not tell me which one throws the error... It's happening as soon as I run  #macro1 #macro2 Running macro1 works fine and changes the value, running macro2 works fine and rolls on the table. Running the combined macro crashes (yes the tables are named with numbers like "131" so it takes 13 from the biome query and 1 from the dc query) My before working macros without simplification: macro1 !setattr --charid -OeY7LIhzE43tP8BmGQW --DCVariable|?{DC Reached|DC 10, 1|DC15, 2|DC 20, 3} macro2 !rt[Delimiter:BR] &{template:default} {{Foraging Plants}}{{You Found =[[[[@{VariableStorage|DCVariable}]]t[[[[[?{Biome|Arctic, 1|Blightshore, 2|Coast, 3|Desert, 4|Feywild, 5|Forest, 6|Grasslands, 7|Hill, 8|Mountain, 9|Savannah, 10|Swamp, 11|Urban, 12|Underground, 13|Volcanos, 14}]][[@{VariableStorage|DCVariable}]]]]]]]}} I'm well aware that you are not my personal code checker, tho. And I don't want to take advantage of your kindness. It's super appreciated that you are helping me!

No worries about taking up my time looking over your code... as the author of the Metascript Toolbox I want it to be useful to people and to work for them. Besides, if I find an error while helping you, then I can correct that and make it better for everyone! As far as your the error you're getting, that sort of error isn't indicative of a script failing; that's the sort of error you get for badly formed inline roll syntax. For instance, if you have an inline roll like: [[@{VariableStorage|DCVariable}d20]] ...and you swap out that attribute reference for a Fetch construction without deferring the roll: [[@(VariableStorage.DCVariable)d20]] ...that will throw the error you saw, because we're not giving Fetch enough time to return the value from that attribute before the inline roll tries to run. The inline roll sees the Fetch construction and doesn't know what to do with it. Try changing your second macro to be: !rt[Delimiter:BR] &{template:default} {{Foraging Plants}}{{You Found =[\[\[\[\@(VariableStorage.DCVariable)\]\]t[\[\[\[\[\?{Biome|Arctic, 1|Blightshore, 2|Coast, 3|Desert, 4|Feywild, 5|Forest, 6|Grasslands, 7|Hill, 8|Mountain, 9|Savannah, 10|Swamp, 11|Urban, 12|Underground, 13|Volcanos, 14}\]\][\[\@(VariableStorage.DCVariable)\]\]\]\]\]\]\]}} If that doesn't work, I'll have to mock up your game setup (tables, etc.) so I can better test it. Post back to let us know.

Hi, still the same problem. Here is the code again exactly as I'm using it (just to be safe) with your last recommendations copied and pasted in: macro1 !setattr --charid -OeY7LIhzE43tP8BmGQW --DCVariable|?{DC Reached|DC 10, 1|DC15, 2|DC 20, 3} macro2 !rt[Delimiter:BR] &{template:default} {{Foraging Plants}}{{You Found =[\[\[\[\@(VariableStorage.DCVariable)\]\]t[\[\[\[\[\?{Biome|Arctic, 1|Blightshore, 2|Coast, 3|Desert, 4|Feywild, 5|Forest, 6|Grasslands, 7|Hill, 8|Mountain, 9|Savannah, 10|Swamp, 11|Urban, 12|Underground, 13|Volcanos, 14}\]\][\[\@(VariableStorage.DCVariable)\]\]\]\]\]\]\]}} combined #macro1 #macro2 If you want to test it with tables: I wrote them in notepad++ and imported them with the "TableExport" script. Here are the first examples you can just copy and paste into the roll20 chat if the script is installed. !import-table --11 --show !import-table-item --11 --Nothing --1 -- !import-table --12 --show !import-table-item --12 --Frost Lichen --1 -- !import-table --13 --show !import-table-item --13 --Frost Lichen --1 -- !import-table-item --13 --Silverthorn --1 -- !import-table --21 --show !import-table-item --21 --Nothing --1 -- !import-table --22 --show !import-table-item --22 --Nothing --1 -- !import-table --23 --show !import-table-item --23 --Blightspores --1 -- !import-table --31 --show !import-table-item --31 --Gillyweed --1 -- !import-table-item --31 --Dreamlilly --1 -- !import-table --32 --show !import-table-item --32 --Lightning Moss --1 -- !import-table-item --32 --Willowshade fruit --1 -- !import-table-item --32 --White Ghost Orchid Seed --1 -- !import-table --33 --show !import-table-item --33 --Gillyweed --1 -- !import-table-item --33 --Dreamlilly --1 -- !import-table-item --33 --Lightning Moss --1 -- !import-table-item --33 --Willowshade fruit --1 -- !import-table-item --33 --White Ghost Orchid Seed --1 -- !import-table-item --33 --Moonstalker --1 -- Those are the tables for Arctic, Blightshore and Coast with all 3 DCs Here is a list with all my installed scripts, in case there could be a known conflict: - Recursive Table - TokenMod - HTML Builder - TokenController - MonsterHitDice - MapChange - TableExport - CharSetAttr - MetaScriptTollbox (with all the automatically installed dependencies) what confuses me: For instance, if you have an inline roll like: [[@{VariableStorage|DCVariable}d20]] ...and you swap out that attribute reference for a Fetch construction without deferring the roll: [[@(VariableStorage.DCVariable)d20]] ...that will throw the error you saw, because if I use my old macros, without any fetch commands, i still get the Error now..

OK, the extra embedded inline rolls were causing a problem with the processing of the rolls. You (apparently) needed them because your queries had a space before the number... which meant that you had to convert them TO a number so that their values could be concatenated (as strings, again) to become a LARGER number... Somewhere in either the spaces or the extra inline rolls Roll20 was barfing. We can simplify both at the same time... just by removing the spaces from the query values, then removing the extra inline rolls. Here is the working syntax (mocked up and tested in my game): Macro1 !setattr --charid -Oekif8xCmQ_UKIdgW6H --DCVariable|?{DC Reached|DC 10,1|DC15,2|DC 20,3} Macro2 !rt[Delimiter:BR] &{template:default} {{name=Foraging Plants}}{{You Found =[\[\@(VariableStorage|DCVariable)t[\?{Biome|Arctic,1|Blightshore,2|Coast,3|Desert,4|Feywild,5|Forest,6|Grasslands,7|Hill,8|Mountain,9|Savannah,10|Swamp,11|Urban,12|Underground,13|Volcanos,14}@(VariableStorage|DCVariable)\]\]\] }} Combined #macro1 #macro2 {&delay .4} Notice that after the commas of the queries I have removed the space that prepended the numeric values. If we can guarantee that the values already LOOK like numbers (even though they're stored as text on the sheet), they will function as numeric components of an inline roll. A Note on Table Returns RecursiveTables is powerful for returning multiple elements from a table, but its true power comes from its ability to expand nested inline rolls from table returns. That is, if the thing you get back from the table, itself, contains another roll, RT will expand that inline roll... trying to get a "full/final" rendering of all of the rolling that needs to happen. However, in using it, you do have to frame your command line as being owned by RT... Your command becomes a call TO RecursiveTable to have it do all of the work (it begins with "!rt"). The MetascriptToolbox also offers a way to get any or all (multiple) returns from an inline roll, but doesn't need to own the message. It can expose those items in a command line devoted to another script, or in a command line just intended for the chat output. For example: ![[3t[33]]].items({&nl}) {&simple} The operative syntax is the ".items()" attached to an inline roll (or roll marker), within which you put your delimiter. In this case, I used the meta tag for a "new line". Or, as a part of a template, like what you want to do: !&{template:default} {{name=Foraging Plants}} {{You find=[[3t[33]]].items({&nl}) }}{&simple} So your actual command line for macro2 (taking into account the variable storage you want to do) would be: !&{template:default} {{name=Foraging Plants}}{{You Found =[\[\@(VariableStorage|DCVariable)t[\?{Biome|Arctic,1|Blightshore,2|Coast,3|Desert,4|Feywild,5|Forest,6|Grasslands,7|Hill,8|Mountain,9|Savannah,10|Swamp,11|Urban,12|Underground,13|Volcanos,14}@(VariableStorage|DCVariable)\]\]\].items({&nl}) }} Again, if you have a need of the recursive power of RecursiveTables (ie, you have table returns that, themselves, have further inline rolls), you might want to use the RT version. The Metascript Toolbox offers ways to recurse over nested inline rolls, but it can require an extra step of setup (using metascript tags attached to the returned inline rolls in the table). It can take a little experimentation to determine the best path forward for what matches your needs. For example, if each of the entries in the table had a basic inline roll attached to it (ie, instead of just "Gillyweed" the first entry was "Gillyweed [[1d6]]"), the Toolbox would automatically roll those results for you with no further setup: On the other hand, if the entry was "Gillyweed [[3t[33]]]", requiring a further 3 rolls against the table, then the entry would require the ".items({&nl})" syntax to extract the values: (I added another line break following the name just so the new entries would start on their own line.) Now, if "Gillyweed" comes up, it will automatically roll 3 more times against the same table: Again, this is just to demonstrate the tradeoffs of the various approaches of the Toolbox vs RecursiveTables. I know you don't need THIS kind of flexibility in this case, but maybe the Toolbox version of your command line reads more easily to your eye. The point is: RT can do the recursion natively (without extra verbiage) but has to own the message; where the Toolbox potentially requires a little more verbiage/setup in the tables, but then frees you to use the results in any command line. As far as the ease of either approach, YMMV.

Hi once again! Thank you so much! It works now!! For some reason, copying and pasting your code (yes, I've adjusted the charid to the one in my game) didn't work. BUT following your explanation and changing my preexisting macro accordingly DID work. Regarding the recursive table: I use that specific functionality a lot, But I'm impressed with the capabilities of the MetascriptToolbox and will read the info you provided in order to play around with it some more! Thanks again! So very very much!

Oh no.....wait ^^ While the code works beautiful now.......the original problem with the delay persists. q.q It still only adjusts the value AFTER the combined macro is fully resolved.... If the DC is changed, the macro only works right after rolling it twice. It changes the value in the storage sheet before the delay resolves, but it looks like the old value is grabbed and temporarily stored for the calculation before that happens. At this point, I'm willing to give up and just live with two macros I have to roll separately.  Less elegant, but it works. Unless you got another idea?

Yes, my apologies about the character ID. I missed reverting that back to your ID before I shared. As for the delay not working, it is working on my end. My first thoughts about that are: 1) increase the delay (even to an absurd amount, just to see if it has an effect) 2) are you on the experimental sandbox? I'll give it a try in the experimental just to see if that makes a difference, but the closer I can approximate your setup, the better.

Yes, my apologies about the character ID. I missed reverting that back to your ID before I shared. No worries, I ckecked it first. 1) even a delay of 5 or 10 seconds (longer than it takes me to run both macros by hand) → same result 2) switched to experimental -> something weird started to happen: suddenly, macro2 rolled 3 or 4 or 5 times (quite random) on the table. As if it was rolling DCVariable+x times. Never under the actual DCValue, but sometimes on it, sometimes over it. Returning the DCVariable always posted the correct value. Switching back to default sandbox returned it to the usual behavior, and even long delays did not help. Running the macros by hand gave me   as it should. Running the combined one gave me: Incorrectly, but having the delay between posting "setting attributes" and the table with the roll. Would it be easier if I copied my test-stuff-campaign and invited you as GM? (Again, please let me know when it gets too much. Invite link is in your DMs just in case)

If anyone has a similar issue..... What did work now for me, thanks to the help, was having the macros as abilities. macro1 as ability1 macro2 as ability2 combined macro as ability3, calling ability1 and ability2 with delay. In the same charsheet I store the variable value in. Then have a macro calling ability3