Just a heads-up for all the OpenXcom Windows developers. I’ve restructured the project structure to support both x86 and x64 builds, and updated all the dependencies, so next time you pull the latest code it probably won’t compile until you update everything to match. Make sure to clear out all the old dependencies and built files (bin\, deps\ and obj\ folders) and get the new pre-built dependencies. They include the new SDL 1.2.15, SDL_mixer 1.2.12, SDL_gfx 2.0.23 and yaml-cpp 0.3.0, both for x86 and x64 systems. Everything seems to still work on my end, so let me know if you experience any trouble.

The Eclipse and CodeBlocks projects were also dropped from the codebase  since they were hardly used and changed based on people’s individual configurations. If you use these IDEs I suggest just making your own local project.

Developers for other platforms don’t need to worry as you probably aren’t affected.

If there’s anything I’ve proven to myself time and time again, is that I’m not good with Linux. Sure I can install it, use it, maybe play around with a bit if it’s got enough GUIs, but it all reeks of beginner. All I can do is pack an executable in a tarball when there’s a million people out there thet can make fancy packages and distributions and what-not.

So, I’m dropping my Linux testing and binary builds (I don’t think they ever worked anyways).  Instead, I’m welcoming all the Linux enthusiasts to help maintain OpenXcom on their favorite platform of choice. This isn’t a serious commitment, just make sure to test it regularly and let us know of any issues, or even help distribute it by making builds, creating fancy packages or spreading it among your repositories. If it’s good I’ll even place your builds on the Downloads page and credit you.

This doesn’t apply to just Linux though, OpenXcom is a cross-platform project and I love to see it running on new platforms. If you’re good at porting to some esoteric platform or just optimizing for lighter devices, don’t be shy, share your experiences on the forum and help spread OpenXcom everywhere!

Update: There is now a new section on the forums to post and discuss your own builds, and I will try to inform you of upcoming stable releases there. I also welcome you to contribute to the Compiling section on the wiki with instructions for your particular platform/IDE/etc.

Crisis averted. Also courtesy of Ufopaedia.org, I’ve moved all our documentation to a nice and friendly wiki, so it’s easier for everyone to access and ignore all in one place! And you can add your own helpful information like compiling on obscure platforms and what not. If you’ve got any feedback about it, let me know.

Tried to upgrade CPU for better development performance. CPU won’t work. Stuck on my laptop until a replacement arrives. Yay.

Sorry about the slowness of updates lately, but as usual, university work is catching up with me and I have to give it all I got.

In the meantime, I’ve put up a poll about Which development tools do you use? on the forums, for those that compile OpenXcom themselves. This will help us decide which platforms/tools to focus on supporting as we develop the project, so please vote honestly.

Here are the other goodies gchevallereau made just for us.

As a lot of you might have heard, I’ve been working on these mythical things called the rulesets again, but nobody actually seems to have a clear idea of what they’re for. So time for some history.

When I first started OpenXcom, one of the issues I ran into was how to structure all that valuable game logic. Should I just write it all up? Extract it from GEOSCAPE.EXE? Hardcode it in? Load it dynamically? All of it looking like a lot of work.

Then I thought of how the community loves tweaking. Things like XcomUtil and Ufo Extender are really popular by just letting you tweak little things like changing the starting base layout, giving Skyrangers a weapon pod, making Laser weapons more useful, etc. And there’s all those “game modes” people come up with to change things up. It’d be great if I could accomodate all of that easily. So I came up with rulesets.

OpenXcom uses rulesets to define all the game elements. There is a base UFO Ruleset that defines all the countries, crafts, weapons, base facilities, items, aliens, armors, UFOs, etc, etc. Something like this:


---
countries:
- type: STR_AUSTRALIA
fundingMin: 280
fundingMax: 560
labelLon: 2.35619
labelLat: 0.436332
- type: STR_BRAZIL
fundingMin: 300
fundingMax: 600
labelLon: 5.32325
labelLat: 0.0872665
- ...
facilities:
- type: STR_GENERAL_STORES
spriteShape: 1
spriteFacility: 24
lift: false
hyper: false
mind: false
grav: false
size: 1
buildCost: 150000
buildTime: 10
monthlyCost: 5000
storage: 50
- ...
crafts:
- type: STR_SKYRANGER
sprite: 0
fuelMax: 1500
damageMax: 150
speedMax: 760
accel: 2
weapons: 0
soldiers: 14
hwps: 3
cost: 500000
repair: 1
refuel: 50
range: 600
time: 72
score: 200
- ...
...


So if you want to tweak something, you just edit it and modify a value or two. But boy, that’d become a real pain to maintain, having to make your own versions of that big old file just to tweak a value or two. So I decided to make them modular, so that you can combine various rulesets as you please, and they only need to have the things that change. So if you wanted to make a super Interceptor that could detect everything and fly really fast, you’d just need this:

---
crafts:
- type: STR_INTERCEPTOR
speedMax: 99999
range: 99999


Or a Super Stingray launcher that would fire a million missiles a second:

---
craftWeapons:
- type: STR_STINGRAY
reloadCautious: 1
reloadStandard: 1
reloadAggressive: 1


Or a Super Pistol that would nuke the whole map:

---
items:
- type: STR_PISTOL_CLIP
power: 999999
damageType: DT_HE


And if you combined it all, you’d get something like this:

Ok, I get that you’re all anxious to see the project develop, can’t wait to be able to play everything and wanna help as much as you can. I appreciate that. But now with 8 pull requests pending, some even conflicting with one another, let’s get some things straightened out. Here’s the easiest way you can help the project:

TEST THE GAME. Really, we spend so much time developing that we don’t have time to double-check everything and make sure nothing is broken. We put out builds not just to show we’re making progress but so people can play with them and give us feedback to make sure we’re going in the right direction, but we often don’t get much more than “oh wow”s and bugs slip through. One of our goals is to be as bug-free as possible and we can’t guarantee that without your help.

But you still really really really really wanna program something. Ok, here’s some tips on how to do that while still being helpful:

• Please try to follow the coding guidelines and overall structure of the project. I know you all have your own flaming reasons why this style is better than that style and will defend it to the death, but it’s essential that the code stays clean and consistent. I know players only care about stuff working, but if I just accept everything as is, the code can snowball into an ugly mess that nobody feels like maintaining anymore and hinder development, so I review everything that is contributed to ensure this. Feel free to post any questions you have about the code structure and how to best integrate your stuff to avoid delays later.
• Find something useful that nobody else seems to be paying attention to or can figure out. Bug fixes, improvements, optimizations, etc. Things that are easy to review and merge without worrying about the whole impact in the project are the best. Special thanks if it’s something that’s been frustrating us for weeks and you found the perfect solution.
• Don’t try to work on stuff we’re already working on, specially very large stuff at once, this is very disruptive. Being surprised by a sudden huge contribution is not fun if it just makes all our effort useless, so you might think you’re speeding up the process, but it’s impossible to guess where we’re going with a feature just from looking over partially-implemented code and you’ll just take it in a completely different direction. Then we either have to scrap all our work, all your work or do our best to try to mish-mash and integrate it all coherently, either way it’s a lot of effort wasted. When in doubt, post in the forums first to make sure you’re actually being helpful.
• Finally, OpenXcom can’t please all the people all the time. Maybe you have some crazy ideas that don’t really fit the scope of the project so we can’t accept your contribution, but don’t let that stop you! This is open-source, anyone can take it wherever they please, it doesn’t all have to be part of the main OpenXcom. You can just keep developing it separately on your own end, maybe other people like your crazy ideas and wanna see more. Some think everyone keeping their own patches / branches / versions / whatever is an ugly mess, but I think it’s a better approach than trying to turn OpenXcom into this massive bloaty all-encompassing solution for everyone’s wishes with a million else-if’s. We will be incorporating options and moddability into the main project, but only so far.

I don’t mean to sound like a hard-ass, I really do appreciate our community and how helpful you guys try to be, but it can only go so far. Right now I’m working on rulesets and started getting a lot of ruleset contributions, often conflicting with one another, and I just had to stop it before it became a mess. First and foremost, be patient and let us do our job, we’re not going anywhere.

When everything goes wrong …

… you better hope you saved your game.

In other words: panicking and berserking soldiers are implemented, but to compensate for that battlescape savegames -finally- have been implemented too.

Since our savegames are not just binary memory dumps like in the old times, they are readable yaml text files, you’ll have the whole battlescape terrain – tile by tile – nicely described for you to edit and play with.
So you can also clone your own aliens, using copy-paste