koobas.hobune.stream
Resources.Load not giving me all data for a .txt file
I created a map editor in Processing for my game (it's tile based) using two bytes (or two chars) per tile to store the data that I needed. Of course, this leads to a very illegible and unintelligible looking text file, but it has the data that I need.
I can load the file back into processing and regenerate the map just fine, but I can't get the same data into Unity.
I load the map file as a TextAsset so I can read the lines, but it always just says that my file is only one character long, which does nothing for me. Is Unity expecting some different format? I don't understand why it won't read it in like I can in processing. How can I get all of this data into Unity?
Thanks.
Going to need to see the code you use to load that asset...
We need the script you are using in order to help you with a script that is not working as desired.
I don't know what kind of code snippet you want. It's more of a question about the TextAsset class. I was literally just doing this:
TextAsset ta = Resources.Load("Levels/testmap") as TextAsset;
print( ta.text.length );
and it printed 1, which is not right.
I fixed it by using the .bytes member because apparently it has more information than .text?
No, this really shouldn't happen unless something has been embedded at the top of your text file with a null character. $$anonymous$$aybe a bad UTF Byte Order $$anonymous$$ark? open up the source text document with a hex editor and check for any null character at the front of the document, don't be alarmed if you see a UTF Bo$$anonymous$$ as long as it meets the specification as explained here: http://en.wikipedia.org/wiki/Byte_order_mark
I guess that the 2 bytes are not ascii characters so they get interpreted as UTF8 or Unicode characters. What kind of "data" did you store in the file?
The "text" property is meant to access text. If you store binary data in the file you have to use "bytes" of course.
If there's a 0 byte in your data then in a text file it will be treated as an end of file marker. In a binary file it's fine. Using a text file for raw data can also cause trouble when characters used to mark end of line (carriage return and line feed) may get reinterpreted. Sounds like .text acts like a text file while .bytes acts like a binary file.
