Modding Long War 2

Table of Contents
Table of Contents

Overall design

X2EventManager TriggerEvent

X2DownloadableContent calls

New Config Variables

A note on class overrides & existing mod compatibility

How to Integrate New Enemies

How to Integrate New Alien Activities/Missions

How to Integrate New UI

How to Integrate New Soldier Items

How to Integrate New Classes

How to Integrate New Techs

How to Integrate Dark Events

How to Integrate Cosmetics

How to Integrate BehaviorTree Changes

How to Integrate New Bink Movies

How to Integrate New Pod Jobs / Pod AI changes

Default XCOM2 Behavior

Pod Jobs

How to Integrate New Maps

Modding Long War 2

Overall design
The XCOM 2 modding SDK provides a variety of methods for implementing changes to the
base game. The following methods were used in order to implement the Long War 2 overhaul
mod:

1. Modifying base-game config/localization data

2. Adding UIScreenListener instances to trigger UI changes
3. Adding X2DownloadableContentInfo instances for new campaign and load option
changes
4. Creating new templates based on X2DataTemplate
5. Using X2EventManager.RegisterForEvent calls
6. Creating new game states and attaching them as components to existing game states.
7. Modifying existing templates at run-time via X2DataTemplateManager (and extensions)
8. Utilizing UIPanel/etc Unrealscript controls for minor UI changes
9. Overriding classes
10. Exporting, modifying and re-importing GFx assets for major UI changes
11. Modifying umap files and letting them override base-game versions
12. Overriding XComGame.upk

Long War 2 contains the design changes that are too fundamental or too interconnected to exist
within a standalone mod. It contains a replacement XComGame.upk to allow nearly complete
access to the game systems (excepting elements in native code or Core/Engine).

However, changes to the XComGame.upk are as minimal as possible, favoring adding new
interfaces that allow the desired functionality to be implemented via standalone methods. The
goals of this approach are to minimize difficulty when merging updates/patches released by
Firaxis and to increase intercompatibility with other mods. Thus, many of the changes to the
XComGame.upk will consist of adding TriggerEvent calls or adding delegate function hooks --
these will then be utilized using the same approaches as are used in standalone mods. Very
little - if any - Long War 2 specific code is implemented in XComGame, except for
enabling/reusing pre-existing features that were disabled in the base game. In theory you
should be able to run XCOM 2 using the Long War 2 XComGame.upk and play a regular,
unmodded game of XCOM 2 (except for some bug fixes!).

There are three general methods by which new hooks have been added into XComGame.upk
changes : X2EventManager TriggerEvent, X2DownloadableContent calls, and new config
variables. These correspond to adding additional usable elements to options 1, 3 and 5 above.

X2EventManager TriggerEvent
This is a common, flexible method of allowing Mods to hook themselves into core game
functionality. This method allows passing control to any mod that has registered to the event,
and relative order of execution between mods is supported via the event priority. It is efficient,
Modding Long War 2

flexible, and powerful, and has generally been the favored approach used in the development of
LW2.

However, in some cases a TriggerEvent can cause instabilities. This primarily occurs with
classes that are loaded and functionality that is run when loading into the UIShell and during
campaign startup. In this case, an old version of X2EventManager (loaded during the save into
UIShell, which is used to load soldier for the initial screen) persists while creating a new
campaign, which can cause crashes when starting a new campaign with an existing save file
present in savedata. These will typically be identifiable by an assertion in the log complaining
that the event delegate function you are using to service the event does not exist in some
completely unrelated class, often a base-game glass like XComGameState_Item. In many
cases we replaced this functionality with the X2DownloadableContentInfo method in order to
avoid such issues.

Data passing is often handled by the class XComLWTuple, which has been added to the
XComGame package. Note that the functionality of XComLWTuple is identical to that of the
LWTuple previous released in the Toolbox mod, but the two are not directly interoperable. The
XComLWTuple class is used to pass data between XComGame and mod components, while
the LWTuple class is used to pass data directly between mod components.

Not all triggered events use XComLWTuple - it is used only when more data has to be passed
than can be handled by the two EventData / EventSource objects specified in the TriggerEvent
parameters, or when the event is expected to be of type ELR_Immediate, and data has to be
passed back to the triggering function.

An example of this is the addition to X2StatusEffects.GetBleedOutChance :

//reworked to allow DLC/Mods to alter bleedout chance

static function int GetBleedOutChance(XComGameState_Unit UnitState, int OverkillDamage)
{
local int BleedoutChance;
local XComLWTuple Tuple; // LWS added

BleedoutChance = UnitState.GetCurrentStat(eStat_Will) - default.BLEEDOUT_BASE;

//setup Tuple-to pass the overkill damage, and pass/return the bleedoutchance
Tuple = new class'XComLWTuple';
Tuple.Id = 'OverrideBleedoutChance';
Tuple.Data.Add(2);
Tuple.Data[0].kind = XComLWTVInt;
Tuple.Data[0].i = BleedoutChance;
Tuple.Data[1].kind = XComLWTVInt;
Tuple.Data[1].i = OverkillDamage;

`XEVENTMGR.TriggerEvent('OverrideBleedoutChance', Tuple, UnitState);

return Tuple.Data[0].i;
}
Modding Long War 2

X2DownloadableContent calls
These are created in the same manner that Firaxis created them -- by adding new methods to
the X2DownloadableContent class in XComGame. This works, but carries with it a few
restrictions.

Because class X2DownloadableContentInfo is native(Core), its class variable list must remain
synchronized with the native C++ code defines in XCom2.exe. Therefore it is not possible to
add config or localized variables to X2DownloadableContentInfo. However, adding new non-
native functions works without issue. This is how new methods were added to provide additional
hooks.

Further, the X2DownloadableContentInfo method is less efficient. It always loops over all
installed mods, making one call for each mod present. For most mods, this results in the default
nothing happens, but it adds overhead not present in the registered system from
X2EventManager. The order in which X2DownloadableContent calls are made is dependent
upon the mod load order, and there is no way in which to override or control this.

X2DownloadableContentInfo for this reason was only typically used for the following two cases :
1) passing structure data that was awkward/difficult to pass via XComLWTuple, 2) The code can
be run during UIShell / campaign-startup in such a way as to cause fatal CTD errors when using
X2EventManager calls.

An example of such a new call being added is this :

/// <summary>
/// Called from XComParcelManager:ChooseSoldierSpawn
// Allows DLC/Mods to override the soldier spawn point selection logic
// return the selected spawn point, or none to use default logic
/// </summary>
static function XComGroupSpawn OverrideSoldierSpawn(vector ObjectiveLocation,
array<XComGroupSpawn> arrSpawns)
{
return none;
}
Modding Long War 2

New Config Variables

In same cases, new config variables to control new behavior were introduced. Since many of
the classes of interest interface to native code, these new config variables have been placed in
a new classHelpers_LW inside XComGame. A config variable was typically used when the
change we wanted to make was not introducing an extension to the game where we wanted to
run a block of new code, but rather making a very small tweak to existing behavior, generally
adding an if condition around a portion of the base game logic or slightly changing constants.

These config variable can be modified by mod config merging in the same manner as any other
config variable in XCOM 2, allowing mods the ability to change the default behavior of the
game. Without changing the config, the behavior will be identical to the base game functionality.

An example of this is :
// If this flag is set, units in yellow alert will not peek around cover to determine LoS - similar to
// green units. This is useful when yellow alert is enabled because you can be in a situation where a
// soldier is only a single tile out of LoS from a green unit, and that neighboring tile that they would
// have LoS from is the tile they will use to peek. The unit will appear to be out of LoS of any unit, but
// any action that alerts that nearby pod will suddenly bring you into LoS and activate the pod when it
// begins peeking. Examples are a nearby out-of-los pod activating when you shoot at another pod you can
// see from concealment, or a nearby pod activating despite no aliens being in LoS when you break
// concealment by hacking an objective (which alerts all pods).
var config bool NoPeekInYellowAlert;

A note on class overrides & existing mod compatibility

We have attempted to minimize the number of class overrides used by Long War 2, both to
avoid conflicts with existing mods and to allow new mods to override Long War 2 behavior
through their own new class overrides. Note that the initial release of Long War 2 includes
several overrides that have since been removed but which did not make it into the initial release.
These will be removed in an early patch. The remaining class overrides are typically overrides
for UI classes.

The UI classes that are still class overrides remain where we needed to make extensive
changes to the UI elements. Even if we rewrote these changes to not require a class override,
its likely that any other mod overriding these same UI classes would not be compatible despite
something like the Alternative Mod Launcher not reporting a potential conflict, simply because
two mods attempting to radically rewrite the UI will likely interfere with each other unless they
were specifically written to be aware of the other mod. For example, by positioning UI elements
on top of each other, assuming it was using empty space.

The mechanism by which these UI class overrides occurs has changed from base XCOM 2.
The base ModClassOverrides is not recursive -- it wont allow an override of an override. We
have added some specific instances of overriding class which allows these classes to have their
overrides overridden. This functionality will be added with the first LW2 patch to the Helpers_LW
class, with config in XComGameCore.ini. The classes so affected are :

[XComGame.Helpers_LW]
Modding Long War 2

+UIDynamicClassOverrides=(BaseGameClass="UISquadSelect",
ModClass="LW_Toolbox_Integrated.UISquadSelect_LW")

+UIDynamicClassOverrides=(BaseGameClass="UIAfterAction",
ModClass="LW_Toolbox_Integrated.UIAfterAction_LW")

+UIDynamicClassOverrides=(BaseGameClass="UIStrategyMapItem_Region",
ModClass="LW_Overhaul.UIStrategyMapItem_Region_LW")

+UIDynamicClassOverrides=(BaseGameClass="UIStrategyMapItem_Mission",
ModClass="LW_Overhaul.UIStrategyMapItem_Mission_LW")

+UIDynamicClassOverrides=(BaseGameClass="UIOptionsPCScreen",
ModClass="LW_Toolbox_Integrated.UIOptionsPCScreen_LW")

+UIDynamicClassOverrides=(BaseGameClass="UIPersonnel_SoldierListItem",
ModClass="LW_Toolbox_Integrated.UIPersonnel_SoldierListItem_LW")

The format is the same as for regular ModClassOverrides. One of the above classes can be in
turn overridden, although as with regular class overrides, only one mod may do so. The format
for such would be, for example :

+UIDynamicClassOverrides=(BaseGameClass="UISquadSelect_LW",
ModClass="MyNewMod.UISquadSelect_MyNewMod")

As with regular class overrides a replacement class (e.g.

MyNewMod.UISquadSelect_MyNewMod) should extend the UISquadSelect_LW class (and not
the base game UISquadSelect).

One class was left as a regular class Override -- X2Action_MoveClimbWall. This class was a
stub left in base XCOM 2, and no base XCOM 2 units use the associated traversal
eTraversal_WallClimb. This traversal (and the override class) were used in the standalone
AlienPack. This X2Action should work for any character type that allows the associated
traversal.

Long War 2 changes many of the fundamental systems of XCOM 2, so even outside of class
overrides it is probable that many other mods will either not work or not work completely with
Long War 2 simply because the underlying systems they were modding have been changed.
Such conflicts wont be reported by the AML simply because there is no apparently conflict - the
situation is more like mods breaking after an official game patch.

How to get LW2 Version

Long War 2 includes a registered event that other mods can use to easily detect if the full LW2
mod is installed, and what version is present. The event name is 'GetLWVersion'. This event
expects a LWTuple passed as EventData, and fills out the following three values :

Tuple.Data[0].Kind = LWTVInt;
Tuple.Data[0].i = Major;
Tuple.Data[1].Kind = LWTVInt;
Tuple.Data[1].i = Minor;
Tuple.Data[2].Kind = LWTVInt;
Tuple.Data[2].i = Build;
Modding Long War 2

On release, the Build is undefined, but is reserved for possible future use.

How to Integrate New Enemies

New enemy units are added in a manner fairly similar to in base XCOM 2, with a couple of
additions in how they are added to pods. Creating a character template, and XComAlienPawn
archetype (plus any other assets) is unchanged.

The differences are primarily in how units are configured to appear in pods and the job system,
as those systems were reworked a bit for Long War 2.

The first difference is in GameData_CharacterStats.ini.

For all new and base-game enemy types, we have broken down both the
Leader/FollowerLevelSpawnWeights so that each ForceLevel has its own SpawnWeight
defined. This is in contrast to the base game, which defined things as a simpler on/off binary. As
is usually required for mod interoperability, adding units to SupportedFollowers will allow pods to
be created consisting of multiple types.

Long War 2 makes more extensive use of the AI Jobs system. This is defined in AIJobs.ini For
one, the JobListing MoveOrderPriority is now obeyed, so that units with certain certain jobs will
act before others. For example, the Scout Job with MoveOrderPriority=10 will take its action
before a unit with the Hunter Job with MoveOrderPriority=35. We have added some new AIJobs
compared to base XCOM 2.

New units should be assigned to which job types they should try and undertake. Relative priority
is defined by the order in the ValidChar array in each JobListing. To make it easier to integrate a
new enemy type in the AIJobs system, we have defined a new config array variable
JobListingAdditions. The format of this config is :

+JobListingAdditions=(JobName=Soldier, NewCharacterName="SectoidM2_LW",
BeforeUnit="Sectoid", AfterUnit="AdvCaptainM2", DefaultPosition=25)

This contains redundant information to allow inserting a new unit into a JobListing ValidChar
array with uncertainty about what other mods may also be inserting new character types. It will
first attempt to place the new unit before the BeforeUnit. If it cannot, then it will attempt to
insert the unit just after the AfterUnit. If it cannot do that either, then it will insert directly by
index value using DefaultPosition.

One change made by Long War 2 that should not need any modder adjustment is the
composition of alien pods. Long War 2 uses larger pods (generally up to 8). The base XCOM 2
always creates alien pods to be of the same unit type, which could result in a single pod of 8
consisting of identical alien unit types (excepting the leader). In Long War 2, such monolithic
alien pods are broken down into more diverse types. There is a hook available for this purpose
that other mods can tie into if they wish, in X2DLCInfo.PostEncounterCreation.
Modding Long War 2

How to Integrate New Alien Activities/Missions

Long War 2 does not use the Calendar system used by base XCOM 2 for generating and
managing missions. Instead, it creates a new type of object, an Alien Activity. These are
defined via a new X2LWAlienActivityTemplate. These templates are loaded and maintained in
the same way as any other template in XCOM 2, so mods may create new activities and have
them co-exist with the activities created for Long War 2.

Activities differ from missions in that activities are more like containers for one or more
missions. Narratively speaking, these correspond with actions that the strategy AI is performing,
and which the XCOM player will try and counter. Activities allow the handling of multiple mission
chains, as well as managing the mechanics by which activities (and therefore missions) are
discovered through player actions.

All Long War 2 activities are defined in X2StrategyElement_DefaultAlienActivities. These define

the 27 activities available in Long War 2. All missions in Long War 2 (except the 5 Golden Path
missions and the initial Gatecrasher mission) are generated using activities. The Mission
Sources for other mission types from base XCOM 2 are no longer used, so any missions that
depend on those will no longer function.

Activities define a variety of things, some via template, and some via config data associated with
that template. In this way creating an activity is somewhat similar to creating a new ability. Each
activity must at the least define :

1) The mechanism by which it is created, using X2LWActivityCreation (or a child)

a) Each creation class can contain a set of conditions, which determine whether an
activity can be created
b) New activities are checked to be created each 24 hours of in-game time.
2) The mechanism by which it is detected, using X2LWActivityDetectionCalc (or a child)
a) By default, activities are hidden when first created. The player must generally
detect an activity by assigning Rebels to the Intel job, and by scanning with the
Avenger within a region
b) Activities still count down and can have game results even if the player does not
detect them
c) Once an activity is detected, the current active mission for the activity is also
detected
3) What should happen on success/failure of each mission in the activity.
a) Some activities may be terminated with a single successful mission, while others
may require defeating each mission in sequence in order to terminate the activity.
b) Most Long War 2 activities use :
i) TypicalAdvanceActivityOnMissionSuccess
ii) TypicalAdvanceActivityOnMissionFailure
iii) TypicalEndActivityOnMissionSuccess
iv) TypicalEndActivityOnMissionFailure
4) One or more missions defined via config associated with the template. This data exists
in the LW_Activities.ini, and is formatted as so :
[Counterinsurgency X2LWAlienActivityTemplate]
MissionTree[0] = ( MissionFamilies[0]="DestroyObject_LW", \\
Modding Long War 2

Duration_Hours=144, \\
DurationRand_Hours=48 \\
)

MissionTree[1] = ( MissionFamilies[0]="Terror_LW", \\
MissionFamilies[1]="Defend_LW", \\
Duration_Hours=24, \\
DurationRand_Hours=5, \\
ForceActivityDetection=true \\
)

The activity template ValidateTemplate method checks for these required elements, and that
each defined mission exists, reporting any missing items.

Further optional information can be defined for each activity. See Long War 2 activities for
further examples.

How to Integrate New UI

Where possible, we have avoided the use of class overrides for UI elements, but in a few cases
the changes were significant enough that we felt it warranted. As explained in the class
overrides section, these UI elements are :

UISquadSelect => LW_Toolbox_Integrated.UISquadSelect_LW

UIAfterAction => LW_Toolbox_Integrated.UIAfterAction_LW
UIStrategyMapItem_Region => LW_Overhaul.UIStrategyMapItem_Region_LW
UIStrategyMapItem_Mission => LW_Overhaul.UIStrategyMapItem_Mission_LW
UIOptionsPCScreen => LW_Toolbox_Integrated.UIOptionsPCScreen_LW
UIPersonnel_SoldierListItem => LW_Toolbox_Integrated.UIPersonnel_SoldierListItem_LW
As described previously, these classes use new overrides added in LW2 that allow overriding
the override.

Some additional UI classes in LW2 are more conditionally overridden.

UIArmory_Promotion is conditionally overridden

To UIArmory_LWExpandedPromotion
This applies only for the regular soldier class ability UI
To UIArmory_AWCExpandedPromotion_LW
This applies only for the AWC ability viewing/training UI
Neither applies to the psi ability UI and officer ability training UI
UIMission is conditionally overridden
To UIMission_LWCustomMission for most mission types prior to infiltration
To UIMission_LWLaunchDelayedMission for most mission types after infiltration,
in order to launch the tactical mission for an infiltration previously started
Both of these are linked to from the UIStrategyMapItem_Mission_LW override
Care should be taken when creating UIScreenListener classes for these classes, as the exact
class types have changed.
Modding Long War 2

How to Integrate New Soldier Items

In general, new items are added in a manner similar to in base XCOM 2. An X2ItemTemplate,
X2EquipmentTemplate, or X2WeaponTemplate is created, which may reference a
GameArchetype.

However, in Long War 2, nearly all items are built individually. The Schematic system present
in base XCOM 2 is not used in these cases. The reason for this revolves around the infiltration
system, and the need to build up a larger roster to support handling multiple missions
simultaneously. Unlike the fatigue system from Long War for XCom: Enemy Within, the player
now requires enough gear to equip multiple squads of soldiers simultaneously. This in turn
drove the decision to remove schematics.

Long War 2 makes use of template mods that remove the schematic system from all existing
item templates. This is true of other modded-in items as well as the base XCOM 2 items.
However, exceptions to this can be made via the config array SchematicsToPreserve. This was
done for the DLC AlienHunter weapons and armor (since they upgrade an existing piece of gear
instead of creating a new one). If not added to this list, modded in items will also have
schematics removed.

This means that strategy-level costs for building items have to be defined within the individual
item template, and not just at the schematic level. Long War 2 makes use of config data that will
reconfigured existing templates to do this, defined in LW_Overhaul.ini. For example, to adjust
the base XCOM 2 magnetic assault rifle :

+ItemTable=(ItemTemplateName="AssaultRifle_MG", Slots=3, Starting=false,

Infinite=false, Buildable=true, RequiredTech1="MagnetizedWeapons",
RequiredTech2="", SupplyCost=35, AlloyCost=2, CrystalCost=2,
CoreCost=0, SpecialItemTemplateName="", SpecialItemCost=0,
TradingPostValue=15, RequiredEngineeringScore=20, PointsToComplete=150,
InventoryImage="img:///UILibrary_StrategyImages.X2InventoryIcons.Inv_Mag_Rifle")

These same config lines can be used to define how the individual weapon will be used in Long
War 2. These config lines will not be used if the user is not playing Long War 2, allowing a
single mod to be used for both base XCOM 2 and for Long War 2.

One consequence of the removal of schematics is that primary weapons need to be defined
specially so that they display a nice looking inventory image in the Tech popups and when
building them in Engineering. This is done by defining the strInventoryImage value in the item
template to be the image path to the composite image, which in base XCOM 2 was assigned to
the schematic. Alternatively, the InventoryImage field in the Long War 2 ItemTable config can be
used to define this, as shown above.

How to Integrate New Classes

New classes are added in much the same way as in the standalone PerkPack. Each standard
soldier class in Long War 2 has 8 ranks, and 3 choices at each rank. Each Long War 2 class
Modding Long War 2

has its own unique secondary weapon, although this is not a required feature for a new class to
be added.

How to Integrate New Techs

Techs, or Research, is added in much the same way as in base XCOM 2. X2TechTemplates
are created, which add the new tech to the game. Techs still have strategy costs, and define a
length of time to be researched.

As in base XCOM 2, techs can provide an item when research is complete (for example,
Proving Ground). With the removal of schematics, Long War 2 makes more use of this, with
many techs granting a single copy of an item related to the research. For example the tech
LaserWeapons now grants a single AssaultRifle_LS weapon item upon research completion.
This is not technically required, but may be included for balance.

As with weapon items, Techs can be configured specifically for Long War 2 in the
LW_Overhaul.ini, via the TechTable config array. For example :

+TechTable=(TechTemplateName="LaserWeapons", ProvingGround=false,
ResearchPointCost=4000, ModPointsToCompleteOnly=false,
PrereqTech1="ModularWeapons", PrereqTech2="HybridMaterials",
PrereqTech3="", SupplyCost=0,AlloyCost=2,
CrystalCost=5, CoreCost=0, ReqItemTemplateName1="",
ReqItemCost1=0, ReqItemTemplateName2="",
ReqItemCost2=0, ItemGranted="AssaultRifle_LS",
RequiredScienceScore=10)

This TechTable entry is only used if Long War 2 is active, thus allowing a single mod that adds
a tech to be used both for base XCOM 2 and Long War 2.

How to Integrate Dark Events

Dark Events in Long War 2 are defined in a similar manner as in base XCOM 2, but are
processed rather differently.

Instead of a set of 3 Dark Events per GuerillaOps mission as in base XCOM 2, Dark Events in
Long War 2 are tied to two particular activities -- COINResearch and COINOps. The
COINResearch activity handles tactical Dark Events, while COINOps handles strategy Dark
Events. This is defined via the X2DarkEventTemplate.bTactical field.

Long War 2 redefines many Dark Events to be of permanent duration, so once achieved they
persist for the rest of the campaign. These are typically in the form of an upgrade to one or
more ADVENT/alien units. Other Dark Events are of limited duration. Because of this, is it
possible for more than 3 Dark Events to be active at once (indeed, 10+ by mid/late campaign is
not uncommon).

Some base XCOM 2 Dark Events did not work with the reworked strategy layer, so were
removed. This was done in code, not via config. Mods that add sets of Dark Events, only some
Modding Long War 2

of which may be appropriate, may need to check to see if Long War 2 is installed before some
of them are activated.

How to Integrate Cosmetics

Cosmetic mods, including voice packs, should work as-is with Long War 2. Initial testing shows
that many existing cosmetic mods for XCOM 2 work normally with Long War 2.

How to Integrate BehaviorTree Changes

Long War 2 makes some changes to unit AI via the BehaviorTree, but not as extensively as
some other mods. However, we have added some new tools to make it easier for multiple mods
to modify the BehaviorTree in AI.ini while minimizing interference with each other.

Long War 2 defines 2 new config arrays within AI.ini - BehaviorRemovals and NewBehaviors.
These are placed in AI.ini in the section [LW_Overhaul.UIScreenListener_Shell]

BehaviorRemoval will remove a single named entry from the Behaviors array, as defined by
BehaviorName. This allows removal and replacement of targeted lines without the nuclear
option of removing all of them, or trying to match the entire (possibly multi-line) entry.

This removal occurs when the UIShell is loaded, which is after base XCOM 2 loads the config
data and validates it. For this reason, we also added the NewBehaviors, which adds new entries
to the Behaviors array at this same time. After all such config entries are processed, the
BehaviorTree validation is run again, which will display (to log and as redscreen) any errors that
occur due to this modification.

How to Integrate New Bink Movies

The ability for mods to play Bink movies was added
by Firaxis in patch 7 (which also added controller
support). Following are some notes on how to
integrate Bink movies into a mod.

1) The movies should be placed in the

/Content/Movies folder within the mod. This is
slightly inconsistent with where the Movies
folder is placed in the main XCOM 2 folder.
2) Sound for mod Bink movies should be
embedded within the bink movie. Base
XCOM 2 does not embed sound into the Bink
file, but instead plays the sound separately
using the Audiokinetic WWise player. Since
mods cannot add akEvent sounds, the
embedded audio solution is required.
Modding Long War 2

3) For loading screen movies, the Bink audio will always be suppressed and the akEvent
buzzing audio will always be played. We do not know of any workaround for this. Such
loading screen movies should be configured to play in XComEngine.ini in the section
[FullScreenMovie]. Each movie should be added to both the UnskippableMovies and
LoadMapMovies arrays.
4) For in-game cutscene movies, a NarrativeMoment archetype should be created for each
bink to be played. The name of the Bink movie file (without extension) should go into the
str Bink field, and the Bink Audio Event field should be left blank (this will allow
embedded Bink audio to be played).
5) The narrative moment would be used as usual, typically played in an objective, or linked
to a tech :
Template.TechStartedNarrative = "LWNarrativeMoments_Bink.Strategy.Autopsy_MutonM3_LW";

How to Integrate New Pod Jobs / Pod AI changes

Pod Jobs are a new AI system added in Long War 2 to add a new mechanism to AI behavior in
tactical missions. Pod jobs do not replace the XCOM 2 AIJobs system or the behavior trees,
rather they complement them. There is not much in pod jobs that could not be implemented
through new AI jobs or new BTree nodes, but we went with an entirely new system for ease of
implementation and debugging. Debugging BTree behavior is difficult, and writing complex
behaviors in the behavior config files is time consuming and error-prone (entire sections of your
behavior can be silently omitted due to a typo in the config file, for example). The podjob system
also can be applied uniformly to all pods on the map, whereas BTree-based systems may not
work with modded enemy types with custom BTrees, so it should be much more compatible with
BTree-based AI mods.

Default XCOM2 Behavior

In XCOM 2 there were two main aspects to AI behavior. The first part is behavior trees and
AIJobs, which determine how an individual unit will use its action points. These are mainly of
interest to pods that are already active and do not play (much) with how unactivated pods move
around, although there are a few exceptions that modify how pod leaders act in unactivated
pods (especially the special Charger, Defender and Hunter jobs, for example). The second
part of the AI, mostly for unactivated pods, dictate how pods move around on the map via alerts.
This is actually made up of a number of small, separate systems:

1. Green encounter zone patrolling

2. Up- and Down-throttling
3. Crossed-pod interception
4. Special mission-specific map-wide alerts
Most unactivated pods simply patrolled around in their encounter zones. Long War 2 continues
this, but fixes several bugs that would cause pods to stop patrolling in certain circumstances.

Up- and down-throttling guided pods either to or away from XCOM depending on how many
active units there are and the difficulty level. Up-throttling would move pods toward XCOM after
a few turns of no contact, while down-throttling moved pods away from XCOM if they were
Modding Long War 2

already engaged with enough enemies. Both of these systems have been disabled in Long
War 2: the pods will not magically move toward or away from you to attempt to control the
number of engaged enemies at any given time.

The cross-pod interception would cause a pod to stop patrolling and move directly toward
XCOM if the midpoint of the XCOM squad passes the midpoint of the pod along the line of play.
In other words, if you passed a pod without activating it on the way to the objective, it would stop
patrolling and start moving directly toward XCOM. This system has also been disabled.

The map-wide alerts are used only in a small number of special missions (especially Avenger
Defense) and are usually placed by the Kismet script for a mission. For the most part these
integrate tightly with AIJobs for these special missions. The Pod Jobs system does not replace
these mechanisms, but it can co-exist with them (see the special Avenger Defense jobs in the
.ini for example to get LW2s new modified encounters to work in much the same way with the
default Avenger Defense kismet).

Together, these systems controlled how unactivated pods moved around in a mission, and parts
2, 3, and 4 controlled how a pod would move outside its normal patrol encounter zone. Pod
Jobs replaces 2 and 3. The purpose of pod jobs is to get unactivated pods to move around the
map, generally in response to XCOM - the pod manager places alerts for particular pods to get
them to move to particular locations.

Pod Jobs
Pod Jobs are managed by the XComGameState_LWPodManager class. The jobs themselves
are defined in LWPodJobs_DefaultJobSet from templates of type LWPodJobTemplate.
Subclasses of XComGameState_LWPodJob define the job behaviors. The jobs are configured
in XComLW_PodManager.ini, which has a large comment at the top describing all the
configurable options for defining a job.

When most missions begin, all pods are typically in green alert and XCOM is frequently
concealed. In this state pod jobs are not active and most pods will patrol within their zones. Pod
Jobs do not activate until XCOM breaks concealment, and many jobs are not available until at
least one pod enters red alert. At this point the enemies are aware of XCOM and (most) jobs
may begin. Pods that enter yellow alert can take jobs once squad concealment is broken:
something has aroused their suspicion, but until the first pod enters red alert green pods will not
take jobs.

Pod Jobs are processed at the start of each alien turn, where jobs are assigned to eligible pods
and then executed. Job execution generally sets an alert at a particular location on the map
depending on the job in question. Pods that take a job will typically keep that job until they
activate, they reach their destination, or enough turns have passed without being able to
complete the job, but exactly when a job is considered finished depends on the job itself. The
job generally will drop an alert indicating where the pod should move, and the pod will then
move toward that alert during usual AI turn processing. Once a pod activates, pod jobs are no
longer useful for it and the default AI btree takes over.

There are currently 5 jobs defined by Long War 2:

Modding Long War 2

1. Intercept - the pod will move toward XCOMs last known position in an attempt to
engage them.
2. Block - The pod will try to move between XCOM and the objective, but will not move to
engage.
3. Flank - The pod will attempt to move to a position off to the side of XCOM (relative to the
LoP), and wait there, shadowing XCOM as they move until they become engaged with
another pod, at which time theyll move in to attack from the flank. This job shows some
limited communication between pods.
4. Guard - The pod will move to the objective in an attempt to protect it. If it reaches the
objective without finding XCOM, itll give up the job and may choose another.
5. Defend - The pod will move to the objective and stay there even if unengaged, patrolling
in a small area around the objective.
New jobs can be defined by adding job templates to the LWPodJobs_DefaultJobSet. If the job is
a simple move to a particular location they can often be implemented through the existing
XComGameState_LWPodJob_MoveToLocation class without requiring any new code except to
determine and optionally update the position they should move to with delegates set in the
template. If the job is more complex, it may require a custom subclass of
XComGameState_LWPodJob to handle its behavior (see XComGameState_LWPodJob_Flank
for an example, only the flank job required a custom subclass).

How to Integrate New Maps

Parcels that have been created for use with most of the mission types that have been carried
over from the base XCOM 2 game to Long War 2 should work immediately. These missions
generally have unchanged Plot and Parcel required objective tags, so they should pick up any
new plots or parcels that support the corresponding mission types.

Several of the new mission types introduced in Long War 2 do have special plot and/or parcel
requirements, and so new assets wont be selected for these missions unless the required
objective tags are added to the new asset (after verifying they contain the necessary custom
objects). For example, the Jailbreak mission definition contains the following line:

RequiredParcelObjectiveTags[0]="Jailbreak_LW", \\

Only parcels with this tag are chosen. This particular instance requires at least 6 VIP objective
spawn points on the map. Only one of the base game parcels had enough, so we added clones
of some of the other CityCenter parcels with jail cells, adding additional spawn points in the cells
and tagging them with this mission type.

Another example is Rendezvous, which uses a custom plot:

RequiredPlotObjectiveTags[0]="Rendezvous", \\

These plots dont have anything too special, just slots for regular wilderness parcels. They
disallow the more built-up ADVENT facilities, UFOs, or the Avenger from appearing since these
mission types also use Wilderness maps.
Modding Long War 2

Many other new mission types just use standard plot and parcel requirements, and the
additional maps should work with these out of the box. For example, IntelRaid and
TroopManeuvers. The full list of missions and their plot/parcel requirements can be found in
XComMissions.ini.