API Button For Script Call With Double-Hyphen Arguments

Hey, all... I tried this question over in the Macros and Specific Use Forum, but didn't get a response, so I thought I would try it here since it actually deals with passing a script call to an API button. Any help would be appreciated... It seems that if I have a script that utilizes [space hyphen hyphen] as the argument delimiter, like this: !some_script --arg1:value --arg2:value the second ...that I can't put that directly into an API chat button: [Run It](!some_script --arg1:value --arg2:value the second) That produces a non-functional <a> tag without an href, not a button. I'm guessing it is because the -- is getting parsed out in the markdown, but I could be wrong. If I'm right, what is the proper way to escape that series of characters? I have tried using the HTML entity for a hyphen ( -), but that doesn't work.

I've no idea on the escaping question, but I do know that command buttons like that sometimes act different depending on whether you have the actual command inside the () or a link to the command stored on a sheet. Assuming your command works on its own just fine, you could make a character named "Api Commands" (or whatever makes sense to you).  Then you create an ability called "Somescript" (or whatever makes sense to you) that simply contains your api call/command.  Then your command button would look like this: [Run It](~Api Commands|Somescript) That may bypass the whole escaping characters issue completely assuming your command works on it's own as it should.

Just tried this example with TokenMod, and it seems to work.&nbsp; [SetBlue](!&amp;#13;!token-mod --set statusmarkers|blue[]) Put the !&amp;#13 carriage return before the api call as per the following <a href="https://wiki.roll20.net/API:Chat#API_Command_Buttons" rel="nofollow">https://wiki.roll20.net/API:Chat#API_Command_Buttons</a>

It's the : in there.&nbsp; The markdown code simplistically assumes that if the content contains a : that it's a URL.&nbsp; You'll need to double encode it: [test](!foo --bar &amp;amp;#58; baz) &amp;#58; is a colon &amp;amp; is an ampersand. &amp;amp;#58; will become &amp;#58; when submitted to the chat.&nbsp; Then the &amp;#58; will become a : when the button is clicked.

If you're creating these buttons from an API script, you probably only need one level of escaping, you'll just have to test it.&nbsp;

Based on The Aaron's comments, I confirmed that my suggestion does not work if there is a colon in the api call argument. However, I'm now having trouble getting it to work with the suggested replacements. Extending the specific TokenMod example from above to one that uses a colon: !token-mod --set statusmarkers|blue:1 would become the following? [SetBlue](!token-mod --set statusmarkers|blue &amp;amp;#58; 1) This successfully creates the api button, but has no effect when clicked. When I up arrow in the chat window, it shows the following was executed upon clicking the button: !token-mod --set statusmarkers|blue&amp;#58;1 So it seems to not be doing the final replacement. I tried putting the !token-mod --set statusmarkers|blue &amp;amp;#58; 1 into a macro and calling from the api button, but that didn't seem to work, either. Any ideas? Maybe a typo somewhere, or am I just not understanding the explanation?

Are you putting that button into a handout? I've never run into a colon issue in a macro or action. However, my general advice is to try writing macros as actions whenever possible, to avoid a lot of hassle with text replacements. More info here if you decide this will work for you: Macro Character Sheet Chat Menu If you are writing them into a box which wants to reformat them, try cutting the text and re-pasting with Cmd/Ctrl- Shift -V. I have found that often allows a colon to remain without invoking the interpreter.

Keith, if you are asking me: I'm not the OP, I was just experimenting with Aaron's suggestion because I had never run across the colon problem before. I'm reasonably familiar with abilities vs collections macros and html replacements, etc., but this appears to be an interesting case. Hope it's not coming across as hijacking the thread, just trying to reproduce the suggested solution to the OP's problem.&nbsp; EDIT - That being said, just putting the commands in an Ability macro without any html replacements seems to work fine. I put this in the Ability Macro (no replacements), called it "SetBlue" !token-mod --set statusmarkers|blue:1 then ran the following to create the chat button [SetBlue](!&amp;#13;&amp;#37;{Charname|SetBlue}) and it worked no problems.

The comment was more directed at the conversation being had (and to provide some general clarification) than any particular user. I probably could have written it more carefully.

Edited my post above to reflect your comment about ability macros, Keith. This works without any double replacements, etc. Hopefully this is acceptable to the OP

Cool. BTW, the Chat Menu link I gave above has some syntax examples for calling macros and actions from other sources. You can probably write that calling macro very simply as: [SetBlue](~Charname|SetBlue)

Right, haha, I had html replacements on the brain!

This is for my InsertArgs script... which provides you ad hoc argument replacements, so the usage would be to take an existing ability (or ultimately, a macro), drop in your replacement info, and output it directly to chat. Right now, the script has to drop the newly-replaced command line into a holding ability (the default is named: InsertArgs), and then it gives you a button to that ability. If I could instead parse the command line to encode it properly I could avoid extraneous interactions with the sheet, and I'd avoid having 1 default repository for the adjusted command (you can override the destination, but you get the point).

Another use for this functionality would be that I've written an internal function to the InsertArgs script that interrogates the sheet and gives you the entries from a repeating section (as buttons, a query, or a nested query): But to make it work you need to know the section name (obviously), as well as the suffix of the formula element. So I'm writing a helper function to show the structure of the repeating section. ...which lets you see which components you need to reference to make the insertargs script run. That "exec" button runs that particular attribute, but it would maybe be helpful to output the text of that attribute (in this case, a roll template). To do that, I need to (I think), put a button there (labeled: "view") that would store something like: !script --gettext: attributename That script call, when the button was pushed, would output the text of the attribute with a tick mark, so that the template wasn't invoked. I could be overthinking and/or recreating the wheel, there (I have been known to do both, before), but there's multiple ways this could work in my script... if I can get it to work. :-p I will give the encoding a try and report back!

I have a universal chatmenus script that creates a menu from a repeating section (among other things). That idea of interrogating a repeating section and reporting the field names is great one, I think I'll be yanking that when i update the script.

Results... inputting directly into chat (not sending from api): This is the manually entered line I am trying to force into a button: !xray --skills:c --t:-M6ITcGl6_mzPyFNmCGb (which the script should parse as: look at the repeating section "skills", get the "current" value of what you see, for this token_id). Test 1 - Double Encoding [View](!xray --skills&amp;amp;#58;c --t&amp;amp;#58;-M6ITcGl6_mzPyFNmCGb) Result: output &nbsp;&nbsp;&nbsp;&nbsp; : button href &nbsp;&nbsp;&nbsp;&nbsp; : !xray --skills&amp;#58;c --t&amp;#58;-M6ITcGl6_mzPyFNmCGb rcv'd 2nd arg : t&amp;#58;-M6ITcGl6_mzPyFNmCGb expected 2nd : t:-M6ITcGl6_mzPyFNmCGb ==&gt; parsing to ==&gt; ["t","-M6ITcGl6_mzPyFNmCGb"] outcome : failed Test 2 - Single Encoding [View](!xray --skills&amp;#58;c --t&amp;#58;-M6ITcGl6_mzPyFNmCGb) Result: output &nbsp;&nbsp;&nbsp;&nbsp; : non-functional link (not button) href &nbsp;&nbsp;&nbsp;&nbsp; : none rcv'd 2nd arg : never invoked expected 2nd : t:-M6ITcGl6_mzPyFNmCGb ==&gt; parsing to ==&gt; ["t","-M6ITcGl6_mzPyFNmCGb"] outcome : failed I will try inserting from the api, next.

Results... sending from api: I ran the same tests, as above, this time sending from the api... and received identical results. I even tried sending, as the href portion including the initial bang-linebreak: !&amp;#13; !xray --skill... ...but that made no difference. Other ideas, or have I not understood a test case?

Have you tried using a different separator than colon?

I think that's what I'm going to have to do for the internal functions and api invocations of the InsertArgs script itself... but the idea of the script is to let you put hooks into other scripts to give you ad hoc replaceable content. So if I want to take a command line (using some 3rd party script) that needs a colon: !the_best_script --in:The Whole Wide World ...and I save that in an ability named "Marvin," but I wanted to give it replaceable input, I would change Marvin to be: !the_best_script: --in:__hook__ That way, at runtime I could supply the appropriate data using the InsertArgs script, using an internal function "getSomeData": !insertargs --button:Marvin --__hook__:getSomeData() But, InsertArgs is trying to send that replaced line to a button, so I have to process the colon somehow... or (like I'm doing now), dump it into a holding area (an ability named "InsertArgs").

I honestly dont think many other scripts use colons, maybe for the same reason you're having issues. As Aaron mentioned, the roll20 parser is going to treat button text as an URL, and other people will have encountered that issue. It's very very common for scripts to use pipes and hashes for separators, but i cant remember seeing one that used colons. (maybe my memory is misfiring?) NVM: my memory was misfiring. My own script linked earlier uses colons, lol. I shouldnt post when still waking up!

On a related note, the "tick" character (to stop the processing of input) doesn't work when sent from the API? It must bypass the preformatting altogether. For instance, if I have the text of a character attribute and I want to show that to the player, I could prefix it with a tick: `&amp;{template:hoot} {{.... paste it into the Chat (manually), and have the text show up. If I send that same text string from the API, however (including the tick), the tick gets ignored and that template roll gets processed as if executed.

I have always had to change the &amp; at the start of template call to a html entity to avoid it being processed immediately.

First -- ::facepalm:: Thank you. But, second, I'm going to start a new thread, because I am noticing some strange behaviors around what the chat input is running and what it is not.... not sure if it's a bug or not.