Call Abilities from Recursive Rollable Tables

I saw an old post that there was an effort to enable the Recursive Tables mod to call attributes or macros, but I couldn't seem to make this work.  Are the recursive tables capable of calling attributes?

Nevermind, it works!  I was substituting html codes in the called attributes, but apparently that isn't required.  This is great!

Hmmn, I see I posted this previously at <a href="https://app.roll20.net/forum/post/11335359/randomly-calling-macros-or-abilities-via-recursive-tables" rel="nofollow">https://app.roll20.net/forum/post/11335359/randomly-calling-macros-or-abilities-via-recursive-tables</a> Sorry for the redundancy.

Well, I spoke too soon.&nbsp; It works, but only with limited syntax.&nbsp; I&nbsp; couldn't use structures like @{target|Caster?|pb} regardless of whether they had been set in the ability that called the recursive table or in the ability called by the recursive table.&nbsp; I could use something like @{character_name|pb}.&nbsp; I also couldn't use a query, regardless of whether it had been set prior to the recursive table or afterwards. I'd get errors messages like (From RecursiveTables): An Error occured with this message:&nbsp; %{Snake Spirit|SummonConstrictor} Error:&nbsp; Expected "[" but "a" found. I tried replacing the various |,{,},[,], and comma with html codes, to no avail. This did allow me to use ChatSetAttr, but without those structures.&nbsp; The ability I wanted Recursive Tables to execute was !setattr --charid @{Snake Spirit|character_id} --npc_type|'Large Constrictor Snake (Beast, Fiend), Lawful Evil'&nbsp; --npc_hpformula|[[@{target|Caster?|pb}+?{Spell level?}]]d10 where the target and the Spell level? was set in the calling ability.&nbsp; This revised call worked !setattr --charid @{Snake Spirit|character_id} --npc_type|'Large Constrictor Snake (Beast, Fiend), Lawful Evil'&nbsp; --npc_hpformula|[[@{Snake Spirit|pb}]]d10 but of course didn't do what I wanted.

Might be possible to patch it using some features from <a href="https://wiki.roll20.net/API:Meta-Toolbox" rel="nofollow">https://wiki.roll20.net/API:Meta-Toolbox</a> , like a combo of Fetch and Plugger perhaps. Meta-Toolbox is a powerful set of tools, but a little beyond me.

Yep, there are a couple of ways that the MetaToolbox can help, depending on what you need to do. The basic problem you're running into is that you're past the point where Roll20 would pop up the roll query by the time you've engaged with RecursiveTable. The query will happen only in the first message, at the top level of processing. Once that is done and the message is handed off to your stack of installed scripts, you don't get another opportunity for roll queries. Even if a script launches a message, the "player" who would get prompted to respond to the query would be the Script Moderator... who can't supply any answer. One way the toolbox can help is that there's a way to output a button from a table using ZeroFrame. A button would give you the opportunity to start a new "user-generated" message, which would have its own chance for Roll20 parsing (and roll query resolution). Another thing that might work is to use APILogic and test if the query has been filled... A query that goes unresponded-to will remain in the command line as the query text, ie: ?{Pick one} A query that has been responded to will be replaced with the appropriate choice (or text entered). Using APILogic, you could test of the query equals its own formative syntax, and make a different choice if it does (maybe defaulting to a particular character), or maybe outputting a button instead of running it. That only just occurred to me... but if it works, could really be ingenious. Now I have to go test it...

Your discussion of how things work gave me an idea.&nbsp; I put a query in prior to the call to the recursive table, and stored the result in an attribute.&nbsp; Then I called the recursive table, and accessed the attribute.&nbsp; That worked, and provided the current value.&nbsp; Normally, if I store something like that, and access it, I would get the previous value.&nbsp;&nbsp; This opens up some possibilities, if it continues to pan out.

Allow me to introduce the self-healing command line ... (draft 1)... For now, imagine this command line in an ability named TestQuery on the character Kokoro (obviously you can change those details, just adjust the syntax accordingly). The command line performs a logical IF check against the query. On one side of the logical check (where the query went un-prompted-to-the-user), the command line turns itself into a button. The query would typically go unanswered if this ability were pulled into the command line via a Fetch construction, ie, in a roll query where we didn't want to have to do HTML replacements in the TestQuery ability. On the other branch of the conditional (where the query was answered -- meaning this ability was run directly, not nested in a roll query in another ability/macro), the command line runs normally... utilizing the query result. In this simple example, it just reports the choice from the query, but it could be another script's command line (ie, ChatSetAttr, TokenMod, Spawn, etc.). Here is the self-healing line, saved as TestQuery on Kokoro: !{\&amp;if "queryVar" = "?\{What}"}[Roll](~Kokoro|TestQuery){&amp;else}You entered ?{What}.{\&amp;end}{&amp;simple}{&amp;global ([queryVar] ?{What})} And here is an example call where that TestQuery is used in a roll query: !?{Pick macro|TestQuery,%(Kokoro.TestQuery)|Something Else,%(Kokoro.SomethingElse)}{&amp;simple} Running TestQuery on its own, you get the query and the report of your choice: But if you run it from the command line that sources it as a roll query, you get a button: