Creating a macro with a special character as name

Hi there, I would like to create a macro through API, whose name would be the pause symbol ( ⏸). I know that I cannot write this symbol directly in my code, as this will not pass the one-click install. I tried using html entity (⏸) or pictos, but this is not interpreted in the macro name (I see the code, not the symbol). It should be doable, as I can copy-paste the symbol in the macro name and everything is fine. But I once again, I would like to do it through API, and that it goes through the one-click install. Does anyone know how to do that?

Use .toString(16) on the hex of the unicode character: let pauseChar = 0x23F8; let myMacroName = pauseChar.toString(16); Those two lines could, of course, be combined.

Oh, and UnSanity confirms that the character will survive the chat sanitizers, even if it won't survive the 1-click sanitizers: You just have to generate it on the fly, like I did, above. As to whether it will "take" as a macro name... you tell us. =D

Although, now that I look, it appears that character *will* survive the 1-click sanitizers... here it is in the UnSanity code table that has passed through the 1-click: So you should be good just to use it.

timmaugh said: Use .toString(16) on the hex of the unicode character: let pauseChar = 0x23F8; let myMacroName = pauseChar.toString(16); Those two lines could, of course, be combined. Hi timmaugh. Thank you for your help. I tried this code and the macro name displayed in the list, or in the shortcuts is 23f8. In fact, this is a same with a log(myMacroName).

timmaugh said: Although, now that I look, it appears that character *will* survive the 1-click sanitizers... here it is in the UnSanity code table that has passed through the 1-click: So you should be good just to use it. Maybe I don't use the UnSanity correctly to see what is ok for one-click install, but I'm afraid that appearing in this list is not enough to know whether a given symbol is ok. I've had issues with accented characters that appear on this list (such as é or à), which led to crashes in one-click install. Since then, I always escape them from my strings in the code I submit for one-click install.

Thanks to timmaugh's hints, I managed to get it right, using String.fromCharCode(0x23F8)

Hmm... if you wonder if a character might exist in your code but then won't live through the one-click sanitizers, it should be the case that you can check the table of unicode characters in UnSanity. The table is at the bottom of the code closure. Those characters existed in the code at the time that I uploaded it, so if they are readable when you get the script from the Script Library then they should be available for you to include in your code, too. (This is obviously why you would need to "Import" the script rather than install it from the one-click, so that you are able to view the code and see the table.) Every other destination for a script's output (the log panel of a script, a handout, or the chat interface) rely on characters generated at run time using the method I shared with you, so those are better tests for those environments without the limitation of what the 1-click would otherwise strip out.

I see. Then it doesn't cover the issue I've encountered with one-click install : the characters did get through, but they caused the one-click install to crash (with message SyntaxError: Invalid or unexpected token). Of course, nothing happened when importing, and the characters only appeared in strings or comments.  Anyway, since then, I've become very cautious with special characters in one-click install.

I don't think the presence of the unicode characters would present that error...  I have the entirety (I think... I have to double check) of the UTF-16 code set in the UnSanity script. Every character. Those the one-click sanitizers don't like have been replaced with whatever substitute character the sanitizers have established, but the rest are there and none of them are throwing that error. If your code passes validation through a good compiler, it shouldn't break just because the sanitizers sub out a character they don't like. Could it have been some other issue with your code? A different syntax error you happened to catch in the same go of reloading the script for 1-click, or a bad sort of line-break designation?

Well, whatever the issue was, it didn't show with any code checker (esprima, jshint, jslint), and didn't show when I pasted the code into the API window. Everything worked perfectly fine, without any error message, except for the one-click install. And the one-click install started to work again when I systematically replaced all accented characters by html entities. It took me 2 years with a lot of exchanges with Roll20 support, an issue submitted in Roll20 git, asking for help on this forum. Nobody had found what it was. I only tried removing all accented characters from the strings because I was out of ideas. Otherwise, I agree with you, it doesn't make a lot of sense, and I still don't understand how that could have fixed anything. But it did.