OpenXcom (OXC) 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.

OpenXcom Extended (OXCE) is an OXC up-to-date fork managed, improved and supported by Yankes and Meridian. OXCE has many additional features, modding capabilities and even scripts, to say the least.

OpenXcom Extended More (OXCEM) is an OXCE modified fork managed by me (WarStalkeR). Here I implement all the features I desire. Sometimes they are simple, sometimes they are not. Complete list of changes I've made so far (as well as all potential future plans) are listed below along with technical details on how to use them.

See more info at the website and the wiki. OXCEM-specific information is available below.

OXC ruleset reference is available here.
OXCE ruleset reference is available here.

Uses modified code from SDL_gfx (LGPL) with permission from author.

1. Enforceable 32-bit color mode (multi-palette support).
2. Advanced craft/HK and missile dogfight behavior.
3. Bigger craft sprites support for basescape/hangar.
4. Multi-craft hangar mechanics implementation.
5. Modifiable craft size stat and size classifications.
6. Base attacks and missile strikes debug trigger.
7. Option to show distance to target, when selecting crafts.
8. Base sets and New Game starting base selection.
9. Rule flag to hide ufopaedia articles by default.
10. Facility rule flag to use alternative sprite for construction.
11. Base function triggers for arc/event/mission scripts.
12. Active pause for Geoscape and UFO context interactions.
13. Ufopaedia craft articles optional basescape preview.
14. Game Data Viewer option switch for Tech Tree Viewer.

1. Configurable Ufopaedia facilities preview.
2. Multi-sprite rendering mode for bigger facilities.
3. Soldiers and vehicles as modifiable craft stats.
4. Soldier screen direct inventory access shortcut.
5. Craft list reverse sorting via Shift+RMB hotkey.

Note: to use features that already migrated to the main branch, please refer to the official OXCE documentation.

For now this feature is only used to ensure that basescape preview of crafts for ufopaedia craft articles renders them with correct palette and not tries to shift color to match current 8-bit palette that is currently available.

This feature is mostly for those, who intend to modify game's engine itself and not write ruleset-based mods. Great part about this feature is that no change was done to original blitNshade functions - all shading and color shifting functionality works in exactly same manner as before.

Just by calling Surface::setPalette() for a specific surface, you override palette it is going to use for blitNshade, whilst all other surfaces will still inherit palette set via State::setStandardPalette().

If you're to try to use such approach, whilst in 8-bit mode, the engine will render them in closest available colors. However, in 32-bit mode there are no such limits - as long as everything is configured.

The 32-bit mode can enabled via OXCEM options tab and can be enforced via fixedUserOptions and oxceForce32bitMode: true. Important to note that such behavior already exists in engine, when using OpenGL or specific scalers.

Constants values for script files (with example below):
constants:
accelerationPenalty: [10, 10, 10, 10]
accelerationCoefficient: [[10, 20], [15, 35], [20, 50], [25, 70]]

The accelerationPenalty is list of acceleration penalties for various dogfight modes: Standoff, Cautious, Combat and Maneuver. The accelerationCoefficient is list of positive and negative acceleration coefficients for Standoff, Cautious, Combat and Maneuver modes.

Note: if Craft_Acceleration >= Acceleration_Penalty positive coefficient is applied.

Formula Craft_Speed > HK_Speed * (1 + Acceleration_Coefficient/1000 * (Acceleration_Penalty - Craft_Acceleration)) defines, if dogfight mode is available versus hunter killer. It should be noted although Craft_Speed > HK_Speed can be false, but due to high acceleration it is possible to outmaneuver hunter killer. Standoff defines if you can keep enemy HK at 'safe' non-firing distance. Cautious defines if you get Evasion Maneuvers or Cautious/Long Range mode vs hunter killer. Combat defines if you have Standard mode available vs hunter killer. And Maneuver defines if in Standard mode will you be holding enemy craft at distance of your weapons or not. Only Disengage and Postpone behavior didn't change. They still require original Craft_Speed > HK_Speed to be true.

Main change is that if craft has missilePower set to -1 it will become zero damage missile, which is perfect if you want payload dependent missile.

And if craft is a missile (regardless, if its manned or not), it no longer can use craft weapons (even if you will somehow equip it, it just won't shoot). Instead, various stats of the weapon module contribute to final damage of the missile effect, when UFO is hit.

Whilst missile uses same dogfight UI, the effects and usage is different:
Tracking Mode - missile just continues to follow target.
Precision Mode - takes time to close-in to UFO, but does most damage.
Standard Mode - average close-in time, but damage is average as well.
Aggressive Mode - fastest close-in time, but limited damage potential.
Evasive Mode - aggressive, but with better evasion and worse damage.
Disarm Mode - disarm missile and attempt to return it safely to base.

Evasive Mode available, only when Precision Mode isn't: i.e. if missile is too slow and target is a hunter killer.

Since missiles can't use weapons/modules as crafts do, equipped modules contribute instead to various parameters of the missile and it's final damage effect. All speed, armor and fuel related stats affect missiles in exactly same manner, as they affect crafts.

Weapon Stat Effects (for Missiles):
damage - adds flat damage bonus in addition to raw missilePower.
ammoMax - if above 0, damage will be multipled by ammo/ammoMax.
shieldDamageModifier - modifies shield damage multiplier by VAL-100%.
reloadCautious - increases damage roll range for Precision Mode.
reloadStandard - increases damage roll range for Standard Mode.
reloadAggressive - increases damage roll range for Aggressive Mode.
powerBonus - modifies base damage multiplier by flat percent value.

Note: if you will use multiple strike modes during dogfight, the damage effect might be even more random than you think. During dogfight game tracks how much distance missile have traveled in each mode and uses these numbers to select final damage effect against UFO on impact.

Craft values for script files (with example below):
crafts:
- type: BIG_SPRITE_CRAFT
spriteSize: [54, 72]

Now it is possible to define new sprite size for crafts with bigger sprites in order to still keep them centered at original coordinates. The spriteSize values should be exactly as as vertical and horizontal size of your image in pixels. Any change to the sprite size should be even: i.e. you can't use 35x45 pixels sprite.

Allocation of crafts to slot relies on functionalities required by the craft and functionalities are available in the slot. In its nature, functionalities parameter is an std::bitset<64>, i.e. there can be up to 64 different flags. There are two methods of prioritizing craft allocation (craftSortBitCount defines which it will use): by number of flags and by flag order (i.e. later flags are given priority) - this option is implemented to let modder decide, which approach is more suitable in the mod.

Allocation by flag order requires modder to define somewhere in the ruleset dummy facility or dummy craft that will use flags in order of intended sorting: TYPE_CREW, TYPE_VEH, TYPE_SUB, TYPE_AIR, SIZE_S, SIZE_M, SIZE_L & etc. - i.e. TYPE_AIR is more prioritized than TYPE_VEH and the SIZE_L is more prioritized than SIZE_S. Allocation by number of flags disregards the flag order, but requires modder to set additional flags for sorting order.

In addition, for sake of moddability functionalities collection can be reset by submods via RESET_COLLECTION (in functionalities array), but doing so requires modder to re-declare all functionality flags for ruleset entries that already had them prior. Do remember that game loads ruleset files in a reverse order, i.e. from Z to A and not from A to Z.

When game tries to allocate craft into hangar slot, it verifies if hangar slot has all the functionality flags that craft has, if any of them is missing it blocks allocation. In addition, for sake of backwards compatibility, hangars with default slot (i.e. no functionality flags) can house any craft, but crafts with no functionality flags can be housed only in default hangar slots.

To ensure that hangar slot allocation works in any scenarios, even in worst case ones, it does 3 rounds of allocation in total (2nd and 3rd, only if previous attempts have failed). First - find most compatible slot, second - find any slot with no functionality flags and third - just any empty slot. Do note that 3rd method incurs penalties, when attempting to transfer or produce new crafts to the base (counts it towards used up slots): for example, when you have 5 slots, 2 allocated crafts and one of them is misplaced, it will be counted as 2 free slots and not 3.

Facility values for script files (with example below):
facilities:
- type: STR_BAY_HYBRID_GARAGE
crafts: 1
craftsHidden: false
craftOptions:
- {x: 1, y: -3, func: [TYPE_VEH, TYPE_SUB, SIZE_SMALL], hide: false}
- type: STR_BAY_HYBRID_HANGAR
crafts: 1
craftsHidden: false
craftOptions:
- {x: 1, y: -3, func: [TYPE_AIR, TYPE_SUB, SIZE_SMALL, SIZE_MEDIUM]}
- {x: 8, y: 2, func: [TYPE_CREW, SIZE_SMALL], hide: true}

The crafts parameter now also defines number of slots that hangar has. If any hangar slot isn't defined in craftOptions, it will get assigned default properties {x: 2, y: -4, func: [], hide: false} (exact properties of default hangar slot). craftsHidden defines if all crafts are hidden in the hangar slots in the basescape - suitable if you create damaged or sealed variant of facility via refs. The craftOptions defines what properties slots will have: x - horizontal offset of the craft in slot, y - vertical offset, func - functionality flags that slot provides/supports, hide - defines if craft in this slot will be hidden in the basescape.

Craft values for script files (with example below):
crafts:
- type: STR_YOUR_VEHICLE
requiresCraftSlotFunc: [TYPE_VEH, SIZE_SMALL]
- type: STR_YOUR_SUBMARINE
requiresCraftSlotFunc: [TYPE_SUB, SIZE_MEDIUM]
- type: STR_YOUR_AIRCRAFT
requiresCraftSlotFunc: [TYPE_AIR, SIZE_MEDIUM]

The requiresCraftSlotFunc defines which functionality flags slots must have in order to house the craft. In order to house the craft, hangar slot at very least needs to have all the flags that craft has. Hangar slot can have more functionality flags than the craft has, but never less.

Global values for script files (with example below):
craftFuncSettings:
craftClassMap:
- {id: STR_SMALL_VEHICLE, func: [TYPE_VEH, SIZE_SMALL]}
- {id: STR_MEDIUM_SUBMARINE, func: [TYPE_SUB, SIZE_MEDIUM]}
- {id: STR_MEDIUM_AIRCRAFT, func: [TYPE_AIR, SIZE_MEDIUM]}
craftSlotMap:
- {id: STR_SLOT_SMALL_VEH_SUB, func: [TYPE_VEH, TYPE_SUB, SIZE_SMALL]}
- {id: STR_SLOT_MEDIUM_AIR_SUB, func: [TYPE_AIR, TYPE_SUB, SIZE_SMALL, SIZE_MEDIUM]} craftSortBitCount: false
craftPediaShowClass: true
craftPediaShowSlots: true
craftListShowClass: true
craftListClassShort: false

The craftFuncSettings contains all auxiliary configurations that are related to the craft functionalities. The craftClassMap allows to map functionality sets to a strings (for craft ufopaedia articles), craftSlotMap allows to do same for hangar slots (for facility ufopaedia articles), craftSortBitCount defines sorting/priority method, craftPediaShowClass defines if craft's class will be shown in craft ufopaedia articles, craftPediaShowSlots defines if facility's hangar slots will be shown facility ufopaedia articles, the craftListShowClass defines if craft class will be shown in craft list and craftListClassShort defines if shown class (in the craft list) will use minimized _UC strings. Do note if you've enabled craftPediaShowClass or craftPediaShowSlots but didn't map functionality sets to strings, as a fallback, game will show one of the functionality flags.

Additional constant values for script files (with example below):
constants:
baseShortHangarLinks: true defines if additional 'CRAFT>' text is hidden in the basescape, while mouse is over hangar facility with craft. Default value is false.
pediaFacilityLockedStats: true defines, if amount of shown stat rows in in Facility's Ufopaedia entries is limited via this option. Default value is false, because vanilla never had more than 5 parameters.
pediaFacilityRowsCutoff: 5 limits how much stat rows will be shown in Facility's Ufopaedia entries, if option oxcePediaFacilityLockedStats is enabled.
pediaFacilityColOffset: 10 adjusts column in Facility's Ufopaedia entries. Useful, if you have hangars with many types of slots. Number indicates by how much column will be moved to the left.

Strings Localization Guide (with references below):
For each string, in localization files you need to define two entries: standard and short.
en-US:
STR_SMALL_VEHICLE: "Small Vehicle"
STR_SMALL_VEHICLE_UC: "SV"

Standard version will be seen in craft's Ufopaedia entry. Short will be seen in facility's Ufopaedia entry (hangars only). In addition, short version also will be shown if craftListShowClass and craftListClassShort are enabled.

To simulate virtual craft inventory and give modders option to add variants of modules with various drawbacks, the craftSize stats was implemented.

Craft values for script files (with example below):
crafts:
- type: NEW_FANCY_CRAFT
craftSize: 12

By default, craftSize of a craft is 0. Just as any other stats can be set to override default 0, so is the craftSize stat.

Craft Weapon values for script files (with example below):
craftWeapons:
- type: NEW_FANCY_WEAPON
stats:
craftSize: 6

In this example craftSize of 6 means that once this weapon is equipped, craft's size will be increased by 6. If after equipping craftSize will go beyond defined size classification boundaries (if they are defined) and if crafts aren't allowed to change class (via allowClassChange) player will get notification that it can't be equipped.

Craft Class values for script files (with example below):
craftClasses: is a new global value for craft class settings.
sizeClassMap:
500: STR_CLASS_MAX Size range 500 and above. Custom upper limit.
250: STR_CLASS_MASSIVE Size range 250 ~ 499 for massive crafts.
130: STR_CLASS_HUGE Size range 130 ~ 249 for huge crafts.
70: STR_CLASS_LARGE Size range 70 ~ 129 for large crafts.
30: STR_CLASS_MEDIUM Size range 30 ~ 69 for medium crafts.
10: STR_CLASS_SMALL Size range 10 ~ 29 for small crafts.
1: STR_CLASS_TINY Size range 1 ~ 9 for tiny crafts.
0: STR_CLASS_NA Size 0 is compatibility value. Always leave it as is.
-1: STR_CLASS_NO Size range -1 and below. Custom bottom limit. allowClassChange: false useSizeClassMap: true

This feature allows to assigns custom strings to the craft size ranges, as well as define the size classification boundaries. Last entry in the list, i.e. STR_CLASS_NO will not be rendered or shown in Ufopaedia (Analysis will show it anyway in numerical format). The 0 value is reserved for backwards compatibility, since all aircrafts with undefined craft size have their craftSize set to 0, but you can assign any string to it.

allowClassChange: false Allows to enforce craft size changes to be within boundaries declared in the sizeClassMap (i.e. you won't be able install equipment which size stat increases size of modified craft for example from Small Submarine-class into Small Aircraft-class). By default this enforcement is enabled, in order to disable it, set value to true. If sizeClassMap value isn't defined/declared, the option will be ignored.

useSizeClassMap: true Configures Ufopaedia to show size-based classification, instead of one defined via craftClassMap in craftFuncSettings. May be preferable, if mod heavily relies on virtual inventory of crafts for balance.

Strings Localization Guide (with references below):
For each string, in localization files you need to define two entries: standard and short.
en-US:
STR_CLASS_SMALL: "Small"
STR_CLASS_SMALL_UC: "SM"

Standard version will be seen in craft's Ufopaedia entry. Short will be seen in facility's Ufopaedia entry (hangars only). In addition, short version also will be shown if craftListShowClass and craftListClassShort are enabled.

Only works when in options.cfg the option debug: true is set. In Geoscape, if you hold SHIFT, while clicking any of your bases, it will trigger base invasion with random race/faction. If you do so, whilst holding CTRL, missile strike against selected base will be triggered.

Note: If your mod has no ufos: rules with missilePower, then no missile strike will be triggered. In addition, all relevant missions, races and UFOs should be properly linked together, so they can be triggered and spawned normally by the game, otherwise nothing will spawn and you will get error message in log what is missing.

Allows to enable range measurement in Geoscape target list, when you select 'Set The Course' option. In additional column near base name you will get calculated range to target (by default in KM).

Constants values for script files (with example below):
constants:
geoShowTargetCourseRange: true defines if option is enabled or not. Default value is false.
geoTargetCourseRangeMult: 1.8 allows to convert default unit (KM) into anything you want. Default value is 1.0 (for KM).
geoTargetRangeColOffset: -15 allows to adjust range column to specific localization via offset.

Reminder: Please don't forget to modify STR_BASE_DISTANCE localization string to ensure that it related to the chosen geoTargetCourseRangeMult for correct distance measurement with new units.

Base Set values for script files (with example below):
startingBaseSets:
- name: STR_INIT_BASE_UFO_DEFENSE
baseDefault: ...
baseBeginner: ...
baseExperienced: ...
baseVeteran: ...
baseGenius: ...
baseSuperhuman: ...

Allows to enable option oxceStartingBaseSelection that in New Game interface allows user to select custom starting base with different set of starting facilities (of course if there are any beside default ones). Syntax follows same pattern that you can observe in startingBase, startingBaseGenius and other global variables.

Note: game allows to modify 1st depth YAML nodes of the baseDefault and others, just like for startingBase (i.e. facilities, crafts, items & etc) as whole, but because each of them is treated as raw YAML data, it isn't converted to structure and isn't validated. Hence, modders, pay utmost attention to the details and syntax of what you're writing. On the positive side you can even force specific longitude and latitude for a starting base.

Ufopaedia article values for script files (with example below):
ufopaedia:
- id: STR_HANGAR_DAMAGED
requires:
- STR_INSPECT_MACHINERY
text: STR_HANGAR_DAMAGED_UFOPEDIA
hiddenByDefault: true

If hiddenByDefault flag is enabled for the ufopaedia article, once relevant technology (that is required by the article) is unlocked, it is automatically moved into the 'hidden' category (which player can manage manually). This is especially suitable to allow damaged/ruined variants of facilities to open relevant ufopaedia article on middle mouse button click on them in the basescape, but at the same time to prevent clutter in the ufopaedia list and avoid annoyance of seeing damaged/ruined variants, while browsing normally.

Facility rule values for script files (with example below):
facilities:
- type: STR_SOME_FACILITY
altBuildSprite: true

If altBuildSprite flag is enabled for the facility rule, during construction the facility will be using different sprite, if it has 1x1 size or has the flag spriteEnabled set to true. In terms of definitions, alternative sprite should be declared in BASEBITS.PCK via extraSprites next after the the id/number of sprite in spriteFacility parameter. E.g. if facility has 2x3 size and its spriteFacility id is 1120, alternative sprite for this facility should be declared from 1126 (total of 6 sprite tiles of the facility).

Arc/Event/MissionScript rule values for script files (with example below):
eventScripts:
- type: STR_UNNECESSARY_EVENT_SCRIPT
eventWeights:
0:
STR_SOME_UNNECESSARY_EVENT: 100
firstMonth: 0
lastMonth: 0
baseFunctionTriggers:
OH_NO_ANYWAY: true
CPU: true
WELL: true
WAVE: false
WAVE2: false
executionOdds: 100

The baseFunctionTriggers work in exactly same manner, as facilityTriggers and should be declared as such, FUNC_NAME: true/false. Do note that if the base function was never declared in any facility, game will log a warning message. Unlike other parameters, base functions are self-initializing as long as they are declared in any facility (this is how code handles them). At the same time, avoid using them purely for the sake of event/arc/mission triggers. They are intended to unify facilities into 'service' groups and it is possible to declare only 126 base functions in total across all loaded mods.

If active pause feature is enabled, you can pause game in Geoscape just by clicking on the Date/Time UI, or by using Spacebar hotkey. Hotkey and settings themselves are configurable via Options (Controls/Advanced tabs). All settings have proper descriptions and pretty much self-explanatory.

Helps to debug and analyze Arc Scripts, Event Scripts and Mission Scripts. Mostly works when in options.cfg the option debug: true is set. Once debug mode is enabled, go to Options -> Advanced -> Extended, find option Advanced Debugging Options, enable it. Additional sub-section Advanced Debugging will show. In it enable Tech Tree Viewer - Data Mode. Load game, open Tech Tree Viewer via Q hotkey. Typing ASCRIPT, ESCRIPT or MSCRIPT in search will list all Arc/Event/Mission scripts.

Since it is quite spoiler-y, it can be completely disabled in mods via fixedUserOptions through the oxceTechTreeDataView: false and oxceShowAdvancedDebugOptions: false options.

1. Increase craft weapons/system limit to 6 in code.
2. Add motion-scanner stats, similar to medikit and script integration.
3. Scripting links between geoscape and battlescape (i.e. fetching craft data).
4. Prefab kits for fast base deployment. More expensive than normal facilities.
5. Crafts, UFOs and weapons altitude/depth separation and rework.
6. Geoscape base engagement with targets at range (similar to dogfight).

1. Real-Time (with Pause) Geoscape Combat: inspired by X-COM: Apocalypse cityscape real-time combat. But in this case it will occur on geoscape and beside crafts vs UFOs, bases (both player's and hostile's) will join the fray. In addition, capability for bases to shoot passing-by UFOs will add to strategic complexity and variety.
2. Real-Time (with Pause) Battlescape Combat: inspired by X-COM: Apocalypse real-time mode alternative to turn-based for battlescape. This one will be pretty much copy-paste from X-COM: Apocalypse. The only issue is that massive AI rework will be required to ensure that AI can handle real-time combat just as good as player and without cheating, but by using all the tools that player can use, such as scanners & etc.

scannerResolution: 2 - 1 is default one. 2 will allow you to see at longer range, but with reduced precision.
scannerResolutionSwitch: True - if scannerResolution > 1 you can change it during battle. Thus, you will be able to detect targets at longer range, close up and switch resolution for precision.
scannerModes: - script names of modes that will be used to calculate the output (what you see and what you don't). Will be stored as std::vector<std::string>.
- SCANNER_MODE_MOTION_SCRIPT
- SCANNER_MODE_PSIONIC_SCRIPT
- SCANNER_MODE_ELECTROMAGNETIC_SCRIPT
- SCANNER_MODE_HEARTBEAT_SCRIPT
- SCANNER_MODE_DEMONIC_ENERGY_SCRIPT
scannerAddDefault: true - allows to enable default motion scanning mode in addition to custom modes. Irrelevant, if scannerModes has no entries, because it will be working in default mode anyway.

Separate altitude from depth. Allow crafts to have both, allow craft weapons to have max altitude and max depth parameters. Implement different speeds for depth and altitude (difference between underwater and aerial). Also implement similar parameter for UFOs (especially Hunter Killers). In short, proper implementation of a framework for different behavior in air and sea.

Maybe add proper pathfinding for the ground-only and submarine-only units (UFOs and Crafts alike)? Implementation can be very tricky and will require flag that Craft/UFO can't move on the ground or sea level.

Base warfare will be divided into two stages: close-in base warfare (i.e. good old base defense), when UFO is directly above the base and long-range base warfare, when base can take down UFOs from afar. In case of the close-in mode all encounter behavior will stay the same, but weapon handling (including ammo consumption, damage and accuracy) will be fetched from referenced base weapon rule used by long-range mode. Just like crafts, base defenses will require time to reload and rearm after usage.

Long-range base warfare will be performed separately from dogfights and can't be mixed with them. Depending on UFO mission, its behavior will change upon being fired from base: run away (if weak or scout), proceed/ignore (when the mission is priority) and retaliation (moving to base invasion). Any use of the base for warfare will make it visible for the UFO that base attacks. Cloaking device will reduce risk of exposure based on % (custom parameter). Repulsor can be used to slow/ground the UFO based on % (custom parameter).

Base defenses still will allow default parameters for close-in, but if base weapon rule is linked, it will fetch all behavior from it and will ignore standard parameters. Base weapon rule will include these parameters: optimal range, falloff range, accuracy, ammo rack size, rate of fire, salvo size, salvo rate, countermeasure (true/false to intercept incoming projectiles), ammo per salvo (i.e. for flak), damage (per hit), max altitude, max depth.

UFO will have new optional parameters that will allow them to retaliate for long-range base attacks: range, rate of fire, damage (different for base weapon damage numbers, since facilities has no health as is). Facilities will get new parameter resistance (damage accumulates into build time and if goes above, it will downgrade/demolish facility). Since base weapon range is different, even if player can start battle, not all weapon will be able to fire at UFO, just like UFO won't be able to return fire from far away.

On geoscape, once UFO within range of any weapon, player will be notified 1st time and all weapons - 2nd time. It will be possible to enable notification, when UFO comes within range of one more weapon. Notifications will also appear, when UFO is about to leave range of the weapons (configurable). It will be possible to give command to ignore this UFO completely by this base or all bases (and let it move as it wants).

OpenXcom requires a vanilla copy of the X-COM resources -- from either or both of the original games. If you own the games on Steam, the Windows installer will automatically detect it and copy the resources over for you.

If you want to copy things over manually, you can find the Steam game folders at:

UFO: "Steam\SteamApps\common\XCom UFO Defense\XCOM"
TFTD: "Steam\SteamApps\common\X-COM Terror from the Deep\TFD"

Do not use modded versions (e.g. with XcomUtil) as they may cause bugs and crashes. Copy the UFO subfolders to the UFO subdirectory in OpenXcom's data or user folder and/or the TFTD subfolders to the TFTD subdirectory in OpenXcom's data or user folder (see below for folder locations).

Mods are an important and exciting part of the game. OpenXcom comes with a set of standard mods based on traditional XcomUtil and UFOExtender functionality. There is also a mod portal website with a thriving mod community with hundreds of innovative mods to choose from.

To install a mod, go to the mods subdirectory in your user directory (see below for folder locations). Extract the mod into a new subdirectory. WinZip has an "Extract to" option that creates a directory whose name is based on the archive name. It doesn't really matter what the directory name is as long as it is unique. Some mods are packed with extra directories at the top, so you may need to move files around inside the new mod directory to get things straighted out. For example, if you extract a mod to mods/LulzMod and you see something like:

mods/LulzMod/data/TERRAIN/
mods/LulzMod/data/Rulesets/

and so on, just move everything up a level so it looks like:

mods/LulzMod/TERRAIN/
mods/LulzMod/Rulesets/

and you're good to go! Enable your new mod on the Options -> Mods page in-game.

OpenXcom has three directory locations that it searches for user and game files:

Each of these default to different paths on different operating systems (shown below). For the user and config directories, OpenXcom will search a list of directories and use the first one that already exists. If none exist, it will create a directory and use that. When searching for files in the data directory, OpenXcom will search through all of the named directories, so some files can be installed in one directory and others in another. This gives you some flexibility in case you can't copy UFO or TFTD resource files to some system locations. You can also specify your own path for each of these by passing a commandline argument when running OpenXcom. For example:

openxcom -data "$HOME/bin/OpenXcom/usr/share/openxcom"

or, if you have a fully self-contained installation:

openxcom -data "$HOME/games/openxcom/data" -user "$HOME/games/openxcom/user" -config "$HOME/games/openxcom/config"

User and Config folder:

• C:\Documents and Settings\<user>\My Documents\OpenXcom (Windows 2000/XP)
• C:\Users\<user>\Documents\OpenXcom (Windows Vista/7)
• <game directory>\user
• .\user

Data folders:

• C:\Documents and Settings\<user>\My Documents\OpenXcom\data (Windows 2000/XP)
• DATADIR build flag
• C:\Users\<user>\Documents\OpenXcom\data (Windows Vista/7/8)
• <game directory>
• . (the current directory)

User and Config folder:

• $XDG_DATA_HOME/openxcom (if $XDG_DATA_HOME is defined)
• $HOME/Library/Application Support/OpenXcom
• $HOME/.openxcom
• ./user

Data folders:

• $XDG_DATA_HOME/openxcom (if $XDG_DATA_HOME is defined)
• $HOME/Library/Application Support/OpenXcom (if $XDG_DATA_HOME is not defined)
• DATADIR build flag
• $XDG_DATA_DIRS/openxcom (for each directory in $XDG_DATA_DIRS if $XDG_DATA_DIRS is defined)
• /Users/Shared/OpenXcom (if $XDG_DATA_DIRS is not defined or is empty)
• . (the current directory)

User folder:

• $XDG_DATA_HOME/openxcom (if $XDG_DATA_HOME is defined)
• $HOME/.local/share/openxcom (if $XDG_DATA_HOME is not defined)
• $HOME/.openxcom
• ./user

Config folder:

• $XDG_CONFIG_HOME/openxcom (if $XDG_CONFIG_HOME is defined)
• $HOME/.config/openxcom (if $XDG_CONFIG_HOME is not defined)

Data folders:

• $XDG_DATA_HOME/openxcom (if $XDG_DATA_HOME is defined)
• $HOME/.local/share/openxcom (if $XDG_DATA_HOME is not defined)
• DATADIR build flag
• $XDG_DATA_DIRS/openxcom (for each directory in $XDG_DATA_DIRS if $XDG_DATA_DIRS is defined)
• /usr/local/share/openxcom (if $XDG_DATA_DIRS is not defined or is empty)
• /usr/share/openxcom (if $XDG_DATA_DIRS is not defined or is empty)
• the directory data files were installed to
• . (the current directory)

OpenXcom has a variety of game settings and extras that can be customized, both in-game and out-game. These options are global and affect any old or new savegame.

For more details please check the wiki.

OpenXcom requires the following developer libraries:

• SDL (libsdl1.2)
• SDL_mixer (libsdl-mixer1.2)
• SDL_gfx (libsdl-gfx1.2), version 2.0.22 or later
• SDL_image (libsdl-image1.2)

The source code includes files for the following build tools:

• Microsoft Visual C++ 2010 or newer
• Xcode
• Make (see Makefile.simple)
• CMake

It's also been tested on a variety of other tools on Windows/Mac/Linux. More detailed compiling instructions are available at the wiki, along with pre-compiled dependency packages.

Custom compilation instructions from under Ubuntu 20.04 LTS x64 VMware virtual machine only (yes, its weird that I compile windows executable under linux, but it allows to compile everything into a single file). Current instructions for now are only for windows 64-bit executable. Later I will add instructions for linux, android and iOS as well.

Note: make sure that you have enabled 'OpenXcomExMore' VM shared folder and linked it to the actual path, where all OXCE related files reside, such as: C:\Path\To\Cloned\Git\Folder\OpenXcomExMore

If you're compiling the executable for the first time in the virtual machine, follow these instructions.

sudo apt update
sudo apt-get install autoconf automake autopoint bash bison bzip2 flex g++ g++-multilib gettext git gperf intltool libc6-dev-i386 libgdk-pixbuf2.0-dev libltdl-dev libgl-dev libssl-dev libtool-bin libxml-parser-perl zip lzip make openssl p7zip-full patch perl python3 python3-mako python3-pkg-resources python-is-python3 ruby sed unzip wget xz-utils -y
mkdir -p /opt
cd /opt
sudo git clone https://github.com/mxe/mxe.git
sudo chown -R `whoami`: mxe
cd /opt/mxe
sudo make MXE_TARGETS=x86_64-w64-mingw32.static JOBS=8 gcc cmake sdl sdl_gfx sdl_mixer sdl_image yaml-cpp
cd ~/Desktop
mkdir -p ~/Desktop/OpenXcomExM
sudo vmhgfs-fuse .host:/OpenXcomExMore ~/Desktop/OpenXcomExM -o allow_other -o auto_unmount
mkdir -p ~/Desktop/OpenXcomExM/build
cd ~/Desktop/OpenXcomExM/build
export PATH=/opt/mxe/usr/bin:$PATH
/opt/mxe/usr/bin/x86_64-w64-mingw32.static-cmake -DCMAKE_BUILD_TYPE=Release -DDEV_BUILD=OFF -DBUILD_PACKAGE=OFF ..
make -j8
/opt/mxe/usr/bin/x86_64-w64-mingw32.static-strip -d ~/Desktop/OpenXcomExM/build/bin/openxcom.exe
mv ~/Desktop/OpenXcomExM/build/bin/openxcom.exe ~/Desktop/OpenXcomExM/build/bin/OpenXcomExM.exe

If you're re-compiling the executable after shutting down or restarting virtual machine, follow these instructions:

sudo vmhgfs-fuse .host:/OpenXcomExMore ~/Desktop/OpenXcomExM -o allow_other -o auto_unmount
cd ~/Desktop/OpenXcomExM/build
export PATH=/opt/mxe/usr/bin:$PATH
make -j8
/opt/mxe/usr/bin/x86_64-w64-mingw32.static-strip -d ~/Desktop/OpenXcomExM/build/bin/openxcom.exe
mv ~/Desktop/OpenXcomExM/build/bin/openxcom.exe ~/Desktop/OpenXcomExM/build/bin/OpenXcomExM.exe

If you're re-compiling the executable within the same virtual machine session, follow these instructions:

make -j8
/opt/mxe/usr/bin/x86_64-w64-mingw32.static-strip -d ~/Desktop/OpenXcomExM/build/bin/openxcom.exe
mv ~/Desktop/OpenXcomExM/build/bin/openxcom.exe ~/Desktop/OpenXcomExM/build/bin/OpenXcomExM.exe