Script parser or automated daemon replacing special characters that break API command buttons

I am generating an API command button to resolve opposed combat. It's a two step process so it's necessary to call the function twice as the defender has to make a choice of how to defend themselves. This works by replacing certain special characters with escape codes as recommend under the API command button wiki chat = "[RESOLVE](!STRIKE selected=@{target|token_id} | " < some parameters >")"; However overnight or at some time, or other an automated script replaces @ with the @ symbol which is what the escape code @ represents. and replaces it with this line chat = "[RESOLVE](!STRIKE selected=@{target|token_id} | " < some parameters >")";   when output with sendChat results in the malformed line !STRIKE selected=target|token_id | <some parameters> instead of this being output to the chat window !STRIKE selected=@{target|token_id} | < some parameters > The end result is my script has been broken by the unknown automated process.

That's odd. The html replacements are supposedly in there to precisely prevent that problem. Before pinging a dev, I'll see if I can find one of our macro experts to lend a hand.

Jack, can you share your code? That will help with the debug process. I'm betting that you have @ written directly in the script. The HTML is parsed by the coder so you have to enter HTML replacements in something like this: Chat = 'yada yada yada &'+'#64;'

This has been especially annoying for newlines in the past for me. Just use a function like this at the bottom of your code and call it for special characters. htmc = o => '&#' + o.charCodeAt(0) + ';'; Then you can call your strings like  chat = "[RESOLVE](!STRIKE selected="+htmc('@')+"{target|token_id} | " < some parameters >")"; Or use templates so you don't have to concat so much. chat = `[RESOLVE](!STRIKE selected=${htmc('@')}{target|token_id} | ${< some parameters >})`; Not ideal but it's better than turning on your campaign with bugs that weren't there yesterday...

Thanks everyone for your help. Splitting @ into two two parts solved the problem. The API parser should not be substituting alternate values into java string constants.