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..