I’m using Tiled in a mini-game which is using an interpreter. I want to associate a MapObject with a little script, that my game code will execute. It would be so convinient for me if the script could fit in the tmx file.
So I added a custom property for my MapObject, named “script”, type String.
Then I hit the […] button next to the field. It opens a Text editor in Tiled. And I type my script in it :
{
printMessage(“hello”);
}
But it makes my script executer fail : my tokenizer has trouble with unexpected characters. Indeed, when I go to the tmx file, the property is recorded as this :
{
printMessage( " ; hello " ;);
}
The " are one problem, but even the opening bracket { and the first \n cause a problem. However, when I write the exact same script in a classic textfile, that I load traditionnaly with Java to retrieve its content, all is well. And something strange : when I retrieve the script from the tiled custom property, and when I check it with println in the console, the strange characters aren’t there, it prints the good script.
I’m really lost on this one. Is there a way to edit preferences for the Tiled text editor for string custom properties? Is this file even ASCII?
Are you passing the same string to your tokenizer that you tested when you used println? It would be really strange if println somehow replaced the HTML entities. What language are you using?
It sounds to me like your HTML parser is not substituting the HTML character entities. Maybe it’s an option you could enable?
Sorry for the lack of precision, I’m using Java and Libgdx. But you just answered my question anyway : I didn’t see that the tmx file was using UTF-8 encoding. I resolved the issue by having the input retrieved from the tmx file converted to regular java UTF-16. Thank you very much!
EDIT
Ok I’m an idiot. I did convert the stream of bytes, that I get from the tmx file, to UTF-16, but it didn’t solved the problem, I just tested the wrong String afterwards !! No, it gave me japanese kanjis instead, and my tokenizer still didnt like it.
I checked the stream of bytes that I got 1) from my textfile 2) from the tmxfile. Result : they are the same, but in the tmx file, \n are now \r\n. I just changed my tokenizer to recognize \r as another separator and all works well now!
I checked on the internet, \n -> \r\n seem to be a Unix/Windows problem. I recently had a problem with Linux and had to switch to Windows to continue working (yeah another sentence I never thought I would pronounce in my life), and so I’m currently using Tiled on Windows. Maybe that’s the cause of all this.
Usually this is only a problem if you load a text file as binary. As far as I know they get automatically converted to simply \n when you explicitly open a file in text mode.
In Java, this may be done by using a FileReader instead of a FileInputStream.
