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:

For those compiling OpenXcom yourselves, there’s a bug in SDL_gfx 2.0.21 and older that causes the globe to be rendered incorrectly, so until a new version is released, you’ll need the latest SDL_gfx SVN to fix it. If you’re using the pre-built Windows dependencies, they’ve been updated for this so just download them again to fix it.

Yes, for those of you without a compiler (which, if my forum is any guess, is like only 1% of my fanbase), rejoice! You get to try out some more stuff!

To recap what’s been added since the last build:

• Base building.
• Hangar building.
• Craft equipping (incomplete).
• Textured and lighted globe (incomplete).
• Cosmetic enhancements.
• And the traditional bugfixes and performance enhancements.

And our contributors never stop! If you think your particular platform or compiler wasn’t supported before, maybe it’s time to look at the Compiling page again, it just keeps on growing!

What would you rather see implemented next?  Keep on working on base management and add items to bring us storage, craft equipping, purchase/sell, transfers and maybe more? Or divert to more fun stuff, maybe a crude alien AI for you to detect and intercept?

It’s been boring around here, hasn’t it? Nothing but me talking about programming here and code that. Ugh! Boring! Let’s see what people have been contributing.

Pmprog has been working on getting the globe textured and lighted:

While Shin-NiL got OpenXcom running on a Dingoo:

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? Wrong! This was the original code:

#include "State.h"
typedef State &(State::*EventHandler)(SDL_Event *, int);

You see, that one change crushed it all. By changing the #include to a forward-declaration, the class State is no longer defined, and since a pointer-to-member is different from a regular pointer, suddenly the pointer isn’t being properly allocated, any class constructor that contains it will corrupt the heap or worse and your compiler won’t so much as flinch or warn you about this. Now your program’s exploding all over the place with no code line or visible call stack or anything to grab on to and oh my gawd it’s all so horrible it just hit you out of nowhere you’re completely lost you don’t know what to do your project is dead you lost your job your house burned down your wife traded you for someone who codes Facebook applicatiions and suddenly you just find yourself lying in the streets wondering where did it all go so wrong.

And that is how I survived The Great Include War of 2010.

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.

Our host, Ninex, is planning to upgrade the server this Sunday (4th July), from 12PM to 4PM CEST (maybe more, maybe less).

The website and forum will be down at that time, but you can still access the downloads at the Sourceforge page.

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.  Exciting! Although it’s had me thinking.  By default the game is limited to 8 bases. Whether this is an interface limit, a balance limit or a memory limit, who knows. What do you think? Is it worth allowing the player to build “infinite” bases (if so, how would you suggest adapting the interface for it)? Or is it better kept as it is, because there’s no reasonable use for more and not worth changing the interface for it?

For the most part, fixing bugs is all well and good. Who likes’em? Bunch of ugly buggy annoying things. Just limiting us and getting in our way, right?

But what about those bugs we’ve all grown fond of (because they worked to our advantage)? Our old friends the exploits? Like being able to keep terror sites alive as long as they’re targeted? And not paying bills for crew in transfer? And the apparently infinite alien contaiment? And being able to overflow storage capacity with recoveries? And more stuff like that? I bet you’re not so keen about seeing them get fixed.

So what do you think? Should all bad and good things be fixed for the sake of fairness? Or will you miss those handy little exploits?