That stringn is what is known as a html entity. Certain characters can (or used to, but dont any more) cause problems when making webpages. If you use the < or > characters for instance, they can be confused with programming elements that control the shape of a webpage, so having an alternate way to represent them is handy. When the browser encounters such html characters, it 'interprets' them - that is, it reads them, and converts them into the character they represent. But, in simple terms, that happens after the page is built, so it doesnt break the way the page displays. Some people discovered imaginative ways to use them, as in this: {{[City](!&#13;#City-encounter) This is a hack. the syntax {{[City](!something) was designed as a way to let uses launch API commands. If you do {{[City](!
something) the command doesnt work - but if using an api command, you would never do that. But someone realised if they used a html entity for a linebreak, like so {{[City](!&#13;#City-encounter) then roll20 would be tricked into thinking this was a single-line API command, and it would work. But whenever you open a macro with such a command, roll20 reads an interprets the text so it can display it to you. That process of reading the macro causes the html entity to be turned into the character it represents (a line break) which breaks the code and it doesnt work any more. I hope this is understandable. It's a hack of a technique used in web design to create a feature that roll20 technically doesnt support. Which is why the syntax is weird, and why its flawed in the way things break if you look at them too much. For some reason, this process does not happen on Abilities stored on the Attributes and Abilities tab of a character sheet. You can store html entities there and they will be safe. This leads to many people creating a character called Macros (or similar) and using that to store macros like this one - so that they can be opened and edited safely.