I was just abducted by

It’s been quiet around here, hasn’t it? Maybe development has just slowed down? Maybe there’s nothing interesting to report? Or maybe, just maybe, some big changes are coming… some changes that need to be paced out in order to be very well implemented… some changes that might include actual *gasp* gameplay…

In the meantime, here’s an updated Geoscape to tide you over:

Following up on the last post, I finally fixed the goddamn problem. Oh and what a problem it was. You might think I’m petty for not just giving up, rolling back to the last version and forgetting about it. Well, maybe. But I wasn’t gonna let some stupid little error get the best of me. It’s what separates the men from the boys. The nerds from the geeks. The people who spend their Friday nights debugging me from the ones who have better things to do.

Like all problems, I went to absurd lengths to find the problem until eventually it was staring me right at the face and I was dumbfounded by how ridiculous it was. But I solved it. Me. All alone. My debugging beard grew a little more rugged. For the benefit of all programmers out there that might be reading this (those that don’t care feel free to ignore this), I will explain:

I had pulled every single debugger recommended out there in a desperate attempt to get to the bottom of this. Application Verifier, WinDbg, Purify, BoundsChecker, CrtCheckMemory, the works! They all pointed me to a heap corruption in the constructor that displayed the Language screen. It made no sense. How can a blank constructor cause problems? It should be something that happened before, but none of the code that came before corrupted anything. Commenting things in and out, switching things here and there, nothing seemed to fix it. In the end, none of the code had been changed since last time aside from moving #includes. How can those cause problems???

And then it hit me. These two simple harmless lines of code atop of it all:

class State;
typedef State &(State::*EventHandler)(SDL_Event *, int);

Harmless, right? Just a forward-declaration and a pointer to a member function. Nothing fancy, right?

So OpenXcom’s #includes were becoming a horrible nest of poor standards and slow compiling (to those not familiar with programming, pretend to follow along), so I decided to give them a good old spring-cleaning. In the summer.

The reward? Well now it crashes right on startup! With absolutely no code changes at all, aside from moving #includes around! Not even an error message. Or a pointer to a bothersome code line. Not even a useful call stack. It just up and dies horribly right in my face like I just opened Pandora’s Box.

Let this be e lesson to you kids. Programming is a harsh and cruel mistress that will backstab you everytime you face the other way. And you still keep going back to it. And like it.

It’s been a busy time. Taking care of exams, fixing bugs, adding features, etc. A lot is going on with the code, as you might’ve noticed if you’ve been to the forums, but sadly it rarely translates to anything visible, so here’s a run-down:

– Did some work on fleshing out crafts. Now you can view their info and equip them a bit:

You can also see the highlighting works now.

– Looking into implementing sound effects, they make the game more lively, and they’re one of the more advanced game formats I need to look into eventually.

– After months of hard work, you can finally click on things on the globe! A triumph for us all. 😛 Thanks for the contributors who helped out.

One of the implications is that you can now place and name your starting base:

Soon you’ll be able to actually do things on the globe, build extra bases and so on.