- August is closing ... time to ensure to have at hand latest versions of OpenXcom ... holidays and gaming times are near... yay!
- By now only built .debs under Debian Buster... I guess they work under Stretch, if not, let me know and I'll build them on a VM
- Article updated as Stretch has become current stable release and Buster is now the new testing release.
- At the time of this edit everything explained here for Stretch has been tested working for Buster.
- For that reason I have added latest updated builds for Buster along the original ones for Stretch.
Hi again world!
So, the summer is here! no classes, no exams, less preassure at work, everything seems less stressing...and, well, not everything in life is serious IT sutff!
So, it's time to relax... time to get some of my favourite games and have fun during the evening hours where spanish Sun scorches Earth.
So, let's install OpenXcom on my Debian Stretch workstation, as I did two years ago on Jessie, and have a lot of fun.
What? no .deb packages for Debian Stretch? Why? Stretch is frozen and almost finished... There are for Jessie, why not for Stretch? What's happening?!?
Well, there is a problem with a library, so no easy way to build and play.
But man! there's also a ton of exciting news in the OpenXcom world in the last years wow!
so I said to me... stay calm... Take time to read and investigate about the most popular OpenxCom branches/mods. Then build .deb files for all of them and test them. Once you have a clear idea about the situation... share it! so the TODO is:
Let's share my own builded OpenXcom .deb packages in its current most popular three branches.
Let's share a few notes on how to install them.
Let's explain how to build (well...how I did) OpenXcom on Debian Stretch.
First, solving libyaml-cpp 0.5.3 problem... and disclaimer!
From a system administrator perspective, I have to say that there is a good reason to forget about OpenXcom on Debian Stretch: A pair of libraries needed to build and play it are not present at Debian Stretch repository.
libyaml-cpp is, according to openxcom developer community buggy at its 0.5.2-x versions.
Older 0.5.1-x versions were fine, so until Debian Jessie there was no problem, since 0.5.1-x were present in Debian oficial repository.
Unfortunately, on Debian Stretch (and even Sid) we are stuck to 0.5.2-x variants.
To build and play OpenXcom either 0.5.1-x or 0.5.3-x versions are needed.
So, the choices are to either build libyaml-cpp from sources, or to manually install it using some external .deb package files.
I did the second way, by using .debs from Ubuntu.
The files I've used are the ones from Ubuntu 15.10.1, these ones exactly:
- Needed to play and to build: libyaml-cpp0.5v50.5.3-3-ubuntu15.10.1amd64.deb
- Also needed to build: libyaml-cpp-dev0.5.3-3-ubuntu15.10.1amd64.deb
You can get them at the launchpad.net site, just here.
They just work to me, no conflicts with my current installs, but as always, proceed with caution, try others... you know.
If you decide to install them, note that libyaml-cpp-dev0.5.3-3 depends on libyaml-cpp0.5v50.5.3-3, so, install libyaml-cpp0.5v50.5.3-3-ubuntu15.10.1amd64.deb first.
OpenXcom .deb packages
It is difficult to explain shortly... but, among several expansions, megamods, and plenty of stuff, I'll realized that the big difference among all this mess is what is, in fact, a fork, of openxcom original source code , resulting, at the end, on new compiled OpenXcom binaries, and therefore a different program, and the rest of stuff.
To have an overview of the situation, I recommend reading the following post, written by one of the OpenXcom Developers/Gurus, at the openxcom site forum.
The quantity and quality of the work done by all the people involved in OpenXcom community is awesome! incredible!.. I find no words to explain my admiration... So I strongly recommend to visit openxcom, and openxcom forums to know more about them and their achievements... those guys are all amazing!!!
So, these are the 3 openxcom variants I have packaged On Debian Stretch:
- Vanilla OpenXcom (OXC) package: openxcom(OXC)1.0.0-20170616-1amd64.deb
- OpenXcom Extended (OXCE) package: openxcom(OXCE)1.0.0-20170616-1amd64.deb
- OpenXcom Extended Plus (OXCE+) package: openxcom(OXCE+)1.0.0-20170616-1amd64.deb
Update: And here the new ones for Debian Buster:
- Vanilla OpenXcom (OXC) package: openxcom(OXC)1.0.0-20170628-1amd64.deb
- OpenXcom Extended (OXCE) package: openxcom(OXCE)1.0.0-20170628-1amd64.deb
- OpenXcom Extended Plus (OXCE+) package: openxcom(OXCE+)1.0.0-20170628-1amd64.deb
Update: Summer 2018 ... new ones for Debian Buster:
- Vanilla OpenXcom (OXC) package: openxcom(OXC)1.0.0-20180622-1amd64.deb
- OpenXcom Extended (OXCE) package: openxcom(OXCE)1.0.0-20180622-1amd64.deb
- OpenXcom Extended Plus (OXCE+) package: openxcom(OXCE+)1.0.0-20180622-1amd64.deb
NOTE: The packages do have its dependencies set, so they should automatically install necessary packages (libsdl1.2debian, libsdl-mixer1.2, libsdl-image1.2 and libsdl-gfx1.2-5), but still, THEY DO NOT ask to install the necessary libyaml-cpp package... since it will not work with the one on the repo anyways.
So, You have to deal with this dependency as explained earlier.
Building your own packages
As times goes by, plenty of new feaures, enhacements, bugfixes and so will appear, and my .deb packages will render obsolete.
So, here's how I builded those OpenXcom packages, so the procedure can be repeated (maybe with some changes, specially on the repositories URLs) easily in the future.
A first look at the official documentation may be useful, although I found it quite obsolete, due to the speed of evolution and changes in the project... anyways, here it is: Oficial build info
Preparing your system
NOTE: Chances are that you may squip this if you're a developer or you have previous experience in building from sources.
Prepare your system to build sources:
apt-get install build-essential doxygen gawk git cmake
Install some 0.5.3 version based libyaml-cpp and libyaml-cpp-dev packages, or build that from source.
What I did, using the ones I linked above is the following:
dpkg -i libyaml-cpp0.5v5_0.5.3-3-ubuntu15.10.1_amd64.deb dpkg -i libyaml-cpp-dev_0.5.3-3-ubuntu15.10.1_amd64.deb
Now install most of the needed dependencies:
apt-get install libboost-dev libsdl1.2-dev libsdl-mixer1.2-dev libsdl-image1.2-dev libsdl-gfx1.2-dev
Finally, install the last required dependecy, the xmlto package, but preventing apt to install almost 1Gb of unneeded stuff due to recommended packages:
apt-get install --no-install-recommends xmlto
Now, you may create an appropiate folder structure to put several forks of OpenXcom. If you just want to build one of the versions, you can go ahead and use
/usr/src or whatever directly.
But if you want to build different ones, considering that strightforward git clonning will create an openxcom project folder, I find more confortable, creting a structure such as:
/usr/local/src/openxcom ├── OXC ├── OXCE └── OXCE+
And then cd onto OXC, OXCE or OXCE+ and work there separately for every fork.
Clone and compile
I'm using cmake, but I have successfully build OXC with oldschool autotools too, whereas autotools failed with OXCE and OXCE+... it's up to you... but since cmake worked allways, I sticked to cmake.
I'm pasting the commands I have in my notes, they use my folder structure, but you should change it to yours
I'm using a 24 core Xeon, so, I passed -j12 parameter to make command trying to speed up building, hopping I could commit half of my processors to the task... you may adapt it, or don't use it at all.
For Vanilla OpenXcom (OXC) these are the steps i used:
cd /usr/share/src/openxcom/OXC git clone https://github.com/SupSuper/OpenXcom.git cd OpenXcom mkdir build cd build/ cmake -DCMAKE_BUILD_TYPE=Release .. make -j12
For OpenXcom Extended (OXCE) these are the steps i used:
cd /usr/share/src/openxcom/OXCE git clone https://github.com/MeridianOXC/OpenXcom.git cd OpenXcom mkdir build cd build/ cmake -DCMAKE_BUILD_TYPE=Release .. make -j12
For OpenXcom Extended (OXCE+) these are the steps i used (Note here that Meridian's OXCE+ project has many branches, so I used the fetch and checkout commands to get them and switch to the latest oxce3.5-plus-proto one at this time. This branch may be eventually superseeded by a new one, so check the project):
cd /usr/share/src/openxcom/OXCE+ git clone https://github.com/MeridianOXC/OpenXcom.git cd OpenXcom git fetch git checkout oxce3.5-plus-proto mkdir build cd build/ cmake -DCMAKE_BUILD_TYPE=Release .. make -j12
We're done building, now we want to put aur compiled stuff into .deb packages!
Creating .deb packages
To create .deb packages I use the checkinstall package.
This is an 'easy way', there are more ways to do this, and sure true Debian maintainers do use true 'Debianization' techniques.
These tools, such as checkinstall, are more suitable for system admins that just want to build once, in one system, and deploy the compiled stuff to other systems... and it works great!
So, install checkinstall package:
apt-get install checkinstall
At this time, you're ready to create .deb packages.
The idea is to cd to the folder where you builded the sources and just execute the checkinstall utility.
In my case, I did it three times, after 'cding' into every build folder in my structure:
/usr/local/src/openxcom ├── OXC │ └── openxcom │ └── build ├── OXCE │ └── openxcom │ └── build └── OXCE+ └── openxcom └── build
Checkinstall accepts several things by paramenter, so you can somehow use it in scripts, but the idea is to use its interactive, very intuitive, CLI menu interface.
Since I didn't want to install openxcom at my workstation, but just create the .deb packages and use them afterwards at my home PC, I allways added the parameter --install=no.
If you just execute checkinstall without parameters, the resulting package will be both created and automatically installed!.
Also note that, when building several versions of a same package, same package name, in the same machine, it may be a good idea to add the '--install=no' parameter even if you plan to install some of the builds on that machine, in order to avoid conflicts. So I did, and all went flawlessly, just creating all .debs first, and using them afterwards.
So, this is an example of the checkinstall usage.
Initially, the values on the fields were not as seen here. Instead I had to use the interative menu to select field number, one after one, and change/add values to my taste. What I paste here is the looking of the checkinstall execution and the final values.
root@z800:/home/alex# cd /usr/local/src/OXCE+/openxcom/build root@z800:/usr/local/src/OXCE+/openxcom/build# checkinstall --install=no checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran This software is released under the GNU GPL. The package documentation directory ./doc-pak does not exist. Should I create a default set of package docs? [y]: y Preparing package documentation...OK Please write a description for the package. End your description with an empty line or EOF. >> OpenXcom is an open-source clone of the popular "UFO: Enemy Unknown" ("X-COM: UFO Defense" in the USA release) and "X-COM: Terror From the Deep" videogames by Microprose, licensed under the GPL and written in C++ / SDL. >> ***************************************** **** Debian package creation selected *** ***************************************** This package will be built according to these values: 0 - Maintainer: [ firstname.lastname@example.org ] 1 - Summary: [ OpenXcom is an open-source clone of the popular "UFO: Enemy Unknown" ("X-COM: UFO Defense" in the USA release) and "X-COM: Terror From the Deep" videogames by Microprose, licensed under the GPL and written in C++ / SDL. ] 2 - Name: [ openxcom ] 3 - Version: [ 1.0.0-20170615 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ amd64 ] 8 - Source location: [ build ] 9 - Alternate source location: [ ] 10 - Requires: [ libsdl1.2debian,libsdl-mixer1.2,libsdl-image1.2,libsdl-gfx1.2-5 ] 11 - Provides: [ openxcom ] 12 - Conflicts: [ ] 13 - Replaces: [ ]
Use the index numbers to select what to change.
When done, just hit ENTER with no field number, and the package will be created and put on the same folder... We got our .deb!!!
Using OpenXcom .deb files
Install / Uninstall
I'm not going to talk much about installing, and uninstalling .deb files... Just google around to get detailed info.
Just say that you can do this using Desktop GUI using the utility 'gdebi', so:
apt-get install gdebi
Or you can do the classic way, using the 'dpkg' command.
To install use the -i parameter against the .deb file name, like this:
dpkg -i openxcom(OXCE+)1.0.0-20170616-1amd64.deb
To uninstall use the -r parameter against the installed package name, like this:
dpkg -r openxcom
Puting original X-COM Game Files into place
You need an original copy of an X-COM game: UFO Defense/Enemy Unknown or Terror From the Deep.
You need to copy the original game files to the correct UFO or TFTD folders.
To make things clearer, here is the folder structure of the resulting openxcom installation from one of the .deb packages (There are differences among OXC, OXCE and OXCE+, of course, but the skeleton is the same) in this case, it is OXCE+:
/usr/local/share/openxcom ├── common │ ├── Language │ ├── Resources │ │ └── Pathfinding │ ├── Shaders │ └── SoldierName ├── standard │ ├── Aliens_Pick_Up_Weapons │ ├── Aliens_Pick_Up_Weapons_TFTD │ ├── Limit_Craft_Item_Capacities │ ├── Limit_Craft_Item_Capacities_TFTD │ ├── OpenXCom_Unlimited_Waypoints │ ├── PSX_Static_Cydonia_Map │ ├── StrategyCore_Swap_Small_USOs_TFTD │ ├── TFTD_Damage │ ├── UFOextender_Gun_Melee │ ├── UFOextender_Gun_Melee_TFTD │ ├── UFOextender_Psionic_Line_Of_Fire │ ├── UFOextender_Psionic_Line_Of_Fire_TFTD │ ├── UFOextender_Starting_Avalanches │ ├── xcom1 │ │ ├── Language │ │ ├── MAPS │ │ ├── Resources │ │ │ ├── BulletSprites │ │ │ ├── UI │ │ │ └── Weapons │ │ └── ROUTES │ ├── xcom2 │ │ ├── Language │ │ └── Resources │ │ ├── BulletSprites │ │ ├── Sprite │ │ ├── UI │ │ └── Weapons │ ├── XCOM_Damage │ ├── XcomUtil_Always_Daytime │ ├── XcomUtil_Always_Daytime_TFTD │ ├── XcomUtil_Always_Nighttime │ ├── XcomUtil_Always_Nighttime_TFTD │ ├── XcomUtil_Fighter_Transports │ ├── XcomUtil_High_Explosive_Damage │ ├── XcomUtil_High_Explosive_Damage_TFTD │ ├── XcomUtil_Improved_Gauss │ ├── XcomUtil_Improved_Ground_Tanks │ ├── XcomUtil_Improved_Heavy_Laser │ ├── XcomUtil_Infinite_Gauss │ ├── XcomUtil_No_Psionics │ ├── XcomUtil_No_Psionics_TFTD │ ├── XcomUtil_Pistol_Auto_Shot │ ├── XcomUtil_Pistol_Auto_Shot_TFTD │ ├── XcomUtil_Skyranger_Weapon_Slot │ ├── XcomUtil_Starting_Defensive_Base │ ├── XcomUtil_Starting_Defensive_Base_TFTD │ ├── XcomUtil_Starting_Defensive_Improved_Base │ ├── XcomUtil_Starting_Defensive_Improved_Base_TFTD │ ├── XcomUtil_Starting_Improved_Base │ ├── XcomUtil_Starting_Improved_Base_TFTD │ └── XcomUtil_Statstrings │ │ ├── TFTD <- Copy here TFTD original game files! │ └── UFO <- Copy here UFO original game files!
There, at the end you got the folders:
So, having (as is my case) a 1994 UFO Enemy Unknown original CDRom, the thing goes like this:
cp -R /media/cdrom/* /usr/local/share/openxcom/UFO
And the location of the so-called user folder structure is placed at
There will go the autosaves, config and the like, but, very important, th mods folder goes there!!!
It should be created automatically upon first game execution, I think, not sure, but place there your mods folders.
So, at the end (I show mine) you got the folder structure somehow like this:
/home/alex/.local/share/openxcom ├── mods │ ├── AWACS │ │ ├── Resources │ │ │ └── AWACS │ │ └── Ruleset │ └── AWACS.scenario │ └── Ruleset └── xcom1
Now you're ready to play... just execute openxcom command:
Cool!!!...... Aliens are coming!!!!
Putting OXCE+ Missig Strings into place
At the time of this writing, latest OXCE+ install misses a set of strings, due to a set of (very cool!!!) new features/options added to the builded code that lacks its associated strings.
Without the missing strings, those new features/options can be enabled and disabled anyways, but since the asociated strings are missing, you'll see in the screen a kind variable names, not clear descriptions, so you'll have to figure out or try to deduce from that what makes every new option you enable/disable.
When the missing strings are present, everything goes smooth of course.
The strings are suplied as a mod, and once the mod is enabled, the strings appear in the screen.
The mod, at the moment of this writing is
OXCE+ Missing Strings v1.1 and can be downloadad at openxcom forums, here
I have had dificulties trying to make this mod to work:
Normally, mods are suposed to be detected automatically when put at a
mods folder, that should be cretaed in either the installation folder
/usr/local/share/openxcom/mods, or in the user folder
Uncompressing this mod .zip content (a single folder containing the mod files) on any of those folders didn't made the mod to be detected by OXCE+.
Instead I had to drop the mod folder at the
standard installation folder:
/home/user/.config/openxcom/standard that way the mod is detected... so I did after unzipping:
cp -R '/home/alex/Downloads/OXCE+ Missing Strings' /usr/local/share/openxcom/standard
Neverthless, upon activating the mod, openxcom crashed:
OpenXcom has crashed: Failed to open directory: /usr/local/share//openxcom/standard/OXCE+ Missing Strings Extra information has been saved to openxcom.log. If this error was unexpected, please report it to the developers.
So, My guess was it is probably something related with permissions, and/or (less probable) with those ugly blank spaces in the folder name... so I executed the following:
mv '/usr/local/share/openxcom/standard/OXCE+ Missing Strings' /usr/local/share/openxcom/standard/OXCE+_Missing_Strings chmod 755 /usr/local/share/openxcom/standard/OXCE+_Missing_Strings
And it worked!!!
So, that's all folks!!! .... happy alien hunting!!!!