Sure...
So, now that it's a new day and I'm not half-asleep, I see something I should have changed in the original code, above... and that is that when you use a Fetch construction in a roll, you have to slow the roll down ("defer" it). This is because the order of operations will go:
Roll20 parsing (including rolls) => metascript constructions (like Fetch) => standard scripts
So when Roll20 tries to parse the roll, they'll see the Fetch construction, and it will break the parsers (syntax error). This doesn't happen with Roll20 constructions like:
@{selected|Athletics}
...because by the time the inline roll parsers look at the line, the attribute calls have been resolved out to a number.
In any case, because we'd use a Fetch construction (and we have to, because of wanting to call this from a query), we have to defer the inline roll (which is a ZeroFrame operation). That would look like this:
[\][\]1d20+@(selected|Athletics)\]\]
And since we're going to have to do that, we'll have to turn *this* command into a call to the script engine (starting with a "!")...which means that we should also include a {&simple} in *this* command, too:
!&{template:rolls} {{charactername=@(selected|character_name)}} {{header=Disarm}}{{subheader=Combat Action}}{{roll01=[one-action](https://s3.amazonaws.com/files.d20.io/images/86669372/Pcb4lIrqUua7EyhBvSJzDw/med.png) [\][\]1d20+@(selected|Athletics)\]\] }} {{roll02=...}} {&simple}
Example
Perhaps a simple example would make it easier. Let's say on the character "PublicTables" I have 3 abilities: Heckline, SpaghettiSlap, and Grumpiness. They all follow this format:
!&{template:default}{{name=Heckling}}{{Standard Roll=[[1d20]]}}{{Deferred Roll=[\][\]1d20\]\]}}{{Roll Re-Use=$[[0]] + $[[1]] = [\\][\\] $[[0]] + $[[1]] \\]\\]}} {{Deferred Roll Re-Use=$[[0]] + $[[1]] + $[[2]] = [\\\][\\\]$[[0]] + $[[1]] + $[[2]] \\\]\\\]}} {&simple}
...where the only difference between them is the name portion of the template bearing the name of the ability we are running (this one is "Heckling"). Don't worry too much about what else is going on in that command line -- I'll get to that in a minute. For now, just note that you couldn't retrieve this command via normal Roll20 syntax into a query without doing HTML replacements for the various query-control characters (pipe, comma, and right-brace).
What we can do, however, is use the same query to return the Fetch construction that would (during the metascript portion of message processing) get turned into the command line that we are looking for. So, here is a command line using a Fetch construction to do just that:
!?{Which action?|
Heckling,%(PublicTables.Heckling)|
Spaghetti Slap,%(PublicTables.SpaghettiSlap)|
Grumpiness,%(PublicTables.Grumpiness)}
Something else to note is that I didn't use the pipe-character in the Fetch construction. Although you can use the pipe in Fetch constructions generally (to separate character name and ability/attribute name), you wouldn't want to do that in a query. That's why there is also a period-based Fetch syntax, which I'm using, here. (Leaving the pipe in the example query I shared in my previous post was another mistake I'll correct.)
Here is the above example run twice in succession, once picking Heckling and once picking Spaghetti Slap:
Another thing to note: the query message begins with a bang ("!"). This is because when the Fetch construction is returned from the query, I need the script engine to know it should take action on the message. Every included ability also begins with a bang and includes a {&simple}. Although I could have moved the {&simple} to the line with the initial query, and then removed the bang and the {&simple} from each individual command... and still have the query-command-line still function... that arrangement would have made it so that the individual commands could not have been run without invoking the query. That is, they would not have been able to be run individually and separate from the query -- at least they couldn't have been run in that fashion and still had any Fetch constructions (like @(selected.Athletics) ) resolve properly.
Mule Example
I can give you a proper example of looking up a value from a table (or a mule) if I understand the mechanic of how that works (I am not a Pathfinder or DnD player). I think this is where you are indicating that the success or failure level would factor in a DC level for the target?
EDIT: This requires ZeroFrame 1.1.17, which I just released after finding a bug during my testing to construct this response to you. It will be available in this week's merge, and should be installed automatically if you installed the MetaScriptToolbox from the one-click.
