Binary data problem with Firefox
Monkey Targets Forums/HTML5/Binary data problem with Firefox
| ||
| Hi All, Link to app with problem: http://www.sturdygames.co.uk/GravityEd/ note it works under Chrome, but under Firefoxx, LoadString() fails. The xmlhttprequest succeeds- the data is shown in debug tools in Firefox, which is weird, so I suspect Mime type to be an issue. That said, I've tweaked the code as much as possible and haven't been able to trick it into working. I notice the following in Firefox regardless of my attempts: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must to be declared in the document or in the transfer protocol." Sadly no matter what I do to the source, I cannot get the game running in Firefox. I have tried using overrideMimeType with no luck. Anyone have any suggestions? [edit] How likely is it that I am going to have to Base64 this stuff? (because that is going to slow things down a lot!) |
| ||
| Your server is giving the .dat file the MIME type: "application/x-ns-proxy-autoconfig" which appears to be expected to be single byte encoded text. Your dat file appears to present as UTF16-LE (although the data seems to be nearly all 1-byte chars so half of the file is empty space). You could just try changing the extension to ".txt" or similar if you don't want to mess around with the server. |
| ||
| Thanks, but sadly I tried that. Firefox seems to override it (forcing a mimetype seems to do bugger all too!) - although thinking about it, it runs in Firefox locally, so this pretty much has to be my server, right? The file is indeed all single byte chars, 0-255, each representing a byte-encoded piece of level data. What would I need to do to the server? I'm pretty confident going in and fiddling (It's a VPS) |
| ||
| The file isn't single byte chars though. Just look at it in an appropriate editor. It's a UTF-16 little endian encoded text file. I would have thought .txt would work fine and be sent as text/plain. Maybe try .bin or .exe and see if it comes through as application/octet-stream untouched? As for messing with the server, it depends on what the server is. Apache allows types to be associated with file extensions in .htaccess files. It's not really my area of expertise. |
| ||
| ...*click* Hmmm, that would explain why the dat file is actually 2x the size I'd expect for the amount of data, You might have pointed me in the right direction here, cheers. Strange though, how it works in eveerything except Firefox. :-) Cheers, I have some ideas now. |
| ||
| Yup, the actual file's encoding was the problem. So I stopped monkey from encoding it into unicode by storing only values from 0 to 253. However, these files do not load back in the same at all, as if the unicode detection on load does not match the unicode detection on save. Any ideas on this one? Starting to suspect I should actually just do a "base-128" on the output. |
| ||
| AAAND one more update: I gave up trying to work around storing certain values and just Base64 encoded the bugger, this worked, and since my original levels were double-sized anyway, this didn't actually cause any perceived increase in file size. :-) |
| ||
| I'm currently having some trouble with LoadString() trying to load up my txt file, though with mine it's working in Firefox but not working in Chrome. It's throwing up an error NETWORK_ERR: XMLHttpRequest Exception 101 mojo/app.monkey lines 53 and 137 and also the line in my code with LoadString. I've tried running a bit of code to just load the text file and nothing else and it still doesn't work even for just loading a little text file with just 1 entered in it. Import mojo Function Main() Print LoadString("Map_1.txt") End Would my problem be due to encoding as well and if so how would I go about fixing it. Note that I'm not using Monkey to save the file, I'm saving it from BlitzMax if that makes any difference. |
| ||
| Actually, it's because LoadString fails in Chrome due to (silly, IMO) security concerns. Try it in Firefox, or upload it to a server. Basically it thinks that the file it's loading fron is on a different server and Chrome doesn't allow that. If it's on a server then the problem is gone. It's a bit annoying, I know, but that's how it is. :-( |
| ||
| Also something to note, Monkey tries to automatically detect what encoding the file is using. If you've written out a binary format string from Bmax, you will find Monkey struggles with it. I could not find a way around this problem without hacking the LoadString function. That said, if you Base-64 encode the file, monkey will load it as UTF8, where you will be able to use ReadByte and a Base-64 decoder to correctly get your data from it. You will want to do this if you release to HTML5 anyway due to similar problems transmitting over the net. Personally I used Base-52 for my data. It might sound like a fair bit of work but this was relatively quick and easy even for me and I've only had monkey a short while. Let me know how you get on. I'll try to get round to updating this lib to work fully with my Base-52 encoder. I'll also provide a file converter written with Bmax so you don't have to do any fiddling yourself. :-) It'll be a while though as I am very stretched for time. |
   |