Modding, Project Y4, Warcraft III

Blog 427: Corruption Y4

Since I’ve now installed Warcraft III and The Frozen Throne on my work laptop, I can now progress Project Y4 during lunch hour (don’t worry, I’m a good boy and don’t touch it for the rest of the day).

But because the project is extremely art-heavy, and I can’t be bothered shipping the 1500-odd work-in-progress and reference files plus Magos’ and Wavepad and PSP7 over too, I’ve actually been playtesting and working on the actual game during this time.

This led me to discover that, horrifyingly, saved games were corrupted. A pretty little early crimbo present.

Unhandled Exception

Debugging something as spurious as a crash half-way through loading your map is a difficult task. If it’s in the middle of the game, sure, you can narrow down the events that are firing and home in on some trigger that’s doing something naughty — or if the game exits with no error message (at least, it used to; from the maze generator fiasco, it seems to just kill the offending trigger nowadays) then you’ve had an infinite loop. But during loading? You’ve got nothing but guesswork. At least it always happened, I suppose, rather than being elusive and rare.

Good thing debugging a terrifying system is now my day job.

“So far I feel more like a detective than a software engineer.”

— Jaime Reyes, Deus Ex???

My first instinct was that a model had somehow gone haywire. When you’ve got more than six-hundred imports, most of which are hastily-assembled doodads (you don’t want to know just how many corners I’ve cut in the model department so far), it’s a good place to start. Of course I’ve never seen even hints of a model causing a map crash half-way through reload (it would tend to happen on initialisation, when the model actually appeared on screen), but I’ve had half-dud models do funny things in the past. I don’t know if you remember the RobeTron from the Islands in the Sky series? I had some fun building him where he managed to turn the entire WE interface (yes, that’s a standard Windows setup) team-colour.

Alas, killing all models didn’t solve the problem.

Recent lighting changes have made the entire map a dull brown like Quake II.

Next candidate was obviously the triggers — I’m not particularly experienced with directly writing Jass, and the maze generator had already caused its fair share of problems, so it seemed like another good place to look. File -> Reset Triggers… Shazam! Saved games load successfully.

Project Y4 is no This Wreckage (yet), but at 257 triggers it’s no slouch either (though right now the biggest group are for drone patrol routes rather than a vast swathe of plot-driving cinematics). I started off deleting them in big lumps by category, trying to narrow down the lair of the dirty dirty bug.

Unfortunately, even with no triggers and not a spot of bonus Jass script… Saved games still wouldn’t load.

Can you imagine the prospect of having to rebuild a map’s suite of triggers from scratch? More than two-hundred of them? And having to test throughout, until you finally track down the one that introduces the breaker? Because that thought crossed my mind… It was going to be either that or give up entirely, and we all know I never give up.

Of course I kicked myself when I realised the one segment of the GUI I’d forgotten — variables.

And when I went in there to see the one thing that is completely different about Project Y4 from all other maps that don’t crash on loading saved games… I kicked myself again.

Static Arrays

Yes, it was a problem with the maze generator after all. In order to make sure I had quite enough space in my static one-dimensional array for the two-dimensional maze grid, I had set its length to 8192. This is the maximum length allowed by the variables window.

Apparently, this is a dangerous number; fair enough, it’s the absolute max in a world that isn’t quite sure whether it counts from zero or one (it counts from zero but the entire trigger editor is set up to convince you otherwise). I suppose I found no evidence of this because the people that need such stupendously ridiculously long arrays are hard-core pr0-skript-kiddy types with their multiplayer maps and over-the-top spells that don’t actually do anything… And who saves an AoS to continue later? You’re playing against randoms, if it’s dinner time you just get out of there. Then again, if it kills saved games it probably has other horrifying side-effects. But I digress.

Of course a lengthy (well, attempting to be lengthy) singleplayer adventure is not designed to be completed in one sitting. You’ve got to be able to get back in (or I’d have to do something terrifying with the game cache to implement a new saving system, and I am just not going there) or you’ll never get through.

Reducing the length of this array to a more manageable 2048 solved the problem.

DON'T DO IT

Then, on walking into the WC3C IRC after having fixed it myself, MindWorX was all:

[18:49] <MindWorX> silly rao
[18:50] <MindWorX> Always use 8190 to be safe

Why didn’t you tell me, whyyyyy? Okay, okay, I didn’t ask until right there just before I twigged. Grumble.

The good news is that everything is now fine. I can rest easy.

4 thoughts on “Blog 427: Corruption Y4”

  1. 8192? What kind of a system have you made, geez.
    Also I lol’D.
    The max array size I’ve used is 150, for points lol.
    Also, THAT many triggers already even when the map isn’t finished? :/

    Like

    1. The maze grid can be as big as I want, though the terrain plot has a max of about 25×44 or something. That’s 1100 cells… nowhere near 8192…

      It’s a big project, it needs a lot of triggers and it still needs a lot more.

      Like

And you tell me...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.