I know GM causes file corruptions after loading huge files. I was actually loading all my large background pictures externally using the new functionality in GM7 that allows me to include files in stand alone games. But I wasn't loading the music files nor the character sprites externally. I'm thinking that when I do make a second engine, I'll be loading all those externally as well. Yeah, loading big files in GM is practically asking for a file corruption. I thought loading the backgrounds externally would be enough... But maybe I was wrong. o_o;
Another reason it could have gotten corrupted was that I tried tryed load .wma music into GM. It's an old trick... Even though it's unsupported, GM can play .wma files and they usually have smaller file sizes than mp3's. Maybe that's what caused the corruption. That's my prime suspect and I've already tried running the game after deleting all the music, but I still get the same error message.
All the backups are fried because as far as I know, GM creates backup files whenever you save the game. My suspicion is that the file first got corrupted without me realizing it and I kept saving the corrupted file, thus creating corrupted backup files as well. And this happened, uhh... Over nine times.
I guess my tendency to save my work every five minutes really backfired here. -_-;;
Hmm... The largest background is 800x600 and those were being loaded externally. Recently loaded a 2 mb .wma too. That .wma is looking very suspicious. >:31. Have you added any very large image to the file recently? A lot of people try to load a ginormous background (something over 1600 pixels in one dimension) and find that their game explodes.
Some of the sprites are quite big though. The sprite for the message box is 800x600. And the character sprites are all about 320x400. In retrospect, maybe I should have loaded those externally too. -_-;
Good idea. :3 I will try doing that. But I'm not quite sure it'll change anything since I already tried loading the second room first instead of the first one and that lead to the same error message.2. Can you make a new empty room your starting room and will that load up? It may be that there is some code in your existing starting room that is causing a kaboom.
Hmm... The original .gmk I believe was about 10 mb big. Now it is 7 mb. o_O; As far as I know 10 mb really isn't *that* big for a GM file. It's not like it was a 150 mb big or anything...... It's not *always* a bad sign that the filesize is changing, it does vary somewhat because of the encryption. But dropping 3meg is a little worrying, yes, since it implies that either a pile of data went missing or your game is RIDICULOUSLY HUGE to begin with, which is just asking for it to corrupt...
Ah well, atleast now I can build a better VN engine. I learned lots of cool stuff from doing it once already and I've already figured out alot of ways to improve it from before. I'm actually thinking of open sourcing the engine and making it alot more user friendly so other people could use it now that I'll have to rewrite everything anyways.
Besides, I've been using GM long enough to know that file corruptions are only a part of game making. -_-;
Yosha! Good news everyone! Samu-kun's been working hard all week long and he's just about finished writing both our VN and SHMUP engines!
We're really hoping there won't be any more big problems from now on...
But you always have to prepare for the unexpected.
Mm... I guess just a small peek won't spoil too much...
Yes, you're right. As you can see, this is what a normal battle will look like on Raidaa no Asahi.
We've gotten alot of concerns from some people that integrating a SHMUP into a visual novel will be impossible because the two genres have far too different speeds. Can you explain the measures we've taken to rectify this, Chigara?
EEEHHHH??? A turn-based SHMUP!? How is that possible!?
Shesh, but that sounds so boring, Chigara. Isn't there something a bit more exciting?
