This guide will explain the relationship between a variety of record types that make up Soldiers in SS2. These records are used both for the player to have more options with the make-up of their army, but also to allow for enemy forces to create more interesting fights - or both - perhaps defeating enough enemies can unlock the player's ability to use them!
Note this documentation is based on changes introduced in the 3.1.0 patch (scheduled for release November 2023). If you are not on that version or later yet, some of the explanations in this guide will not match what you see.
UnitTypes are a record that bring together all of the information that makes up a soldier. This includes things like the actual Actor record they are based on, the equipment they wear, the kinds of roles they can fill, recruitment costs, and the circumstances under which the player or NPC armies can use them.
Loadouts define a mix of equipment and/or abilities a Unit is provided, often depending on their rank. In other words, Loadouts are a way for a UnitType to be further empowered as they get higher in rank.
A Loadout is not used independently from UnitTypes, despite us using that terminology in game. Instead, in-game when you assign a Loadout, you are actually changing a Soldier's UnitType, they are then given access to the Loadouts of that UnitType.
A UnitType can define something like a combat role, for example a Sniper, or can get more exotic, defining creatures or equipment, such as a Mutant Hound or a Vertibird.
UnitTypes have two primary purposes: They provide the framework needed for recruiting a fresh unit, and those for transforming an existing soldier into that UnitType.
UnitTypes are Armor records. To create new ones, you'd start by duplicating the SS2_UnitType_Template form.
In this section, we'll go over the script properties of the NPCUnitType script which is on that template. Afterwards, we'll talk about Loadouts, and then the variety of sub-records you'll have been introduced to.
NPCUnitType scripts properties are broken into groups of like-behavior, many of these are hidden by default, you can expand more options by double-clicking the titles in the Properties window.
This group involves properties specific to assigning an existing Soldier as this UnitType (in-game, this is presented as choosing their Loadout).
iRankRequirement: This determines the minimum rank a soldier must be before they can be assigned this rank.
LimitToRaces: This determines which Races can be assigned to it. By default (ie. leaving this blank), it applies to Human, Ghoul, SynthGen1, and SynthGen2, as these all share the same skeleton and can use most of the game's Armor and Weapons.
This group involves the various costs for this Unit in the player's army, setting any of these will override the default costs for that type. In other words, leaving these blank doesn't remove costs, it simply makes SS2 use default costs - for example, the default Recruitment Cost for a unit is 250 caps.
These costs should generally be defined as Virtual Resources, so the player's settlement empire is paying for them. This can be done by selecting ActorValue as the Form Type on the Item, and selecting one of the ActorValue's WITHOUT _Daily that start with SS2_VirtualResource_ in the name.
In addition to defining items and the amount of each, you can also use the iIndex subfield to flag each cost entry with a category, this is used for mechanics that modify costs. Current valid entries for iIndex are: 0 = Caps, 1 = Rations (Food/Water), 2 = Scrap, 3 = Supplies.
AssaultCostOverride: The cost for taking this unit on an Assault. We tend to only use Ammo for these costs, though exceptions can be made for flavor or to make a unit stand out as unique.
RecruitmentCostOverride: The cost for recruiting a new unit of this type. Generally we limit ourselves to Armor and WeaponParts for these costs, but exceptions can be made for flavor or to make a unit stand out as unique.
When a UnitType has RankLoadouts defined, RecruitmentCosts are combined with Loadout costs for the appropriate rank. So don't be alarmed if in-game the recruitment cost ends up higher than you set here.
UpkeepCostOverride: For players using the Soldier Upkeep Costs option, this will override the default daily cost of having this Unit in their army. These costs are meant to help balance powerful units, or add extra flavor.
This group is used to display information to the player in various interfaces.
DescriptionMessage: This is a Message form with Message Box checked in that describes the role of this unit. It will often describe combat purpose and equipment, but can also include things like the creature type, or flavor information.
ShortDescriptionHolder: This is a MiscObject form with the Name field filled out with a very short description to remind the player what the UnitType's purpose is. Think of it as a short sentence summary of the DescriptionMessage information, the player can view the DescriptionMessage if they need all the details.
This group is used to define various changes to the UnitType that will be applied as the Soldier changes rank.
RankLoadouts: This defines a series of up to 5 Loadouts, 1 for each possible rank. You do not have to create 5 Loadouts, the soldier will always be given the highest one available for their rank in this list. We'll dive deeper into Loadout records further down this guide.
You may also wish to define some units with less ranks. For example, if you have a UnitType that requires rank 5, you would only ever have 1 eligible Loadout. Or perhaps you want to only have equipment upgrades every other rank.
RankPerkOverrides: By default, SS2 applies a perk at each rank to slightly buff the health of soldiers as they rank up. Setting this will replace that default small buff for soldiers with this Unit Type.
Ranks: This defines the name of the Ranks themselves this Unit type uses. Ultimately the player gets to decide rank names for their army, but they can choose to acknowledge Unit specific ranks as well. For UnitTypes coming from existing armies, for example the Brotherhood of Steel, it can feel more immersive for them to have their own rank structure, rather than using the Player Faction rank names.
These are copies of the SS2_SoldierRank_Template Armor record. Primarily you just have to fill out the Name field.
In addition to creating Rank Names for your UnitTypes, you can register these Rank Names for use by the player for their army at large. The script properties on this record type involve setting the rules for if/when the player can use them.
This group establishes details used when this UnitType is recruited, ie. spawned into the world. These details are used both by NPC armies spawning them in, as well as the player's Recruitment Queue which is controlled at the War Planner's Desk Recruitment Radio.
bAllowDeskRecruitment: If true, the player can queue these up for recruitment. Otherwise, they will have to get them in other ways - or this can be set to false to prevent the player from having regular access.
Turning off Desk Recruitment is also a way to set up a UnitType that is only meant to be assigned rather than be directly recruited. For example, a UnitType that can only be applied to Automatrons the player builds.
bPlayerCanUseAsRecruitForm: When the player doesn't queue any specific UnitTypes for recruitment, they will default to recruiting Civilian Conscripts. As part of the Recruitment interface on the War Planner's Desk, the player can set other UnitTypes as their Recruit Form (ie their Default UnitType). If this property is set true, the player can choose this Unit as their Recruit Form.
bRecruitedOnly: If true, the player will not be able to assign existing soldiers to this UnitType.
bVirtualUnit: Virtual units do not live in the player's Outposts, and instead are spawned at the battle site during Assaults.
iDefaultClassIndex: ClassIndex is one of the ways we refer to the Soldier Role in code. This setting determines which role this UnitType is assigned when spawned. Available options for this property are defined in the Documentation String at the bottom right portion of the script properties window when this property is selected.
iStartingRankWhenSpawned: If set, the NPC will immediately be ranked up to this when spawned as this UnitType.
ParentFaction: If the unit typically belongs to a Faction, for example Brotherhood Paladins would belong to the BrotherhoodofSteelFaction, this should be set here. It is primarily used for dynamic systems, for example, if an NPC is held captive, it's ParentFaction may try to rescue it.
UnitForm: This is the actual Actor record that is spawned when this unit is recruited. If left blank, the unit will be spawned as a basic settler.
UnitForm is one of the most important parts of a UnitType record for units that can be spawned. Later in this guide, we'll go into great detail into how you should set up Actor records for use as the UnitForm.
This group determined under what circumstances a UnitType can be used.
bNPCArmyUseOnly: If true, the player will never be allowed to use this UnitType in their Army.
bPlayerOnly: If true, only the player will be allowed to use this UnitType in their army.
iMaxPerGame: If set, an Army may only have this many of this UnitType total. If a player attempts to recruit additional, the recruitment will be skipped.
iMaxPerOutpost: If set, an Army may only station this many of this UnitType at any given Outpost. If a player attempts to recruit additional, the recruitment will be skipped.
NPCArmyUseRequirements: A UsageRequirements misc object can be set here to determine whether an NPC army can use this unit. This is useful for having quest stages or globals determine when/if this unit is available to appear in an NPC army.
PlayerArmyUseRequirements: A UsageRequirements misc object can be set here to determine whether the player can use this unit in their army. This is useful for having quest stages or globals determine when/if this unit is available to appear in an NPC army.
For the player, you may only want to use this field to lock out content that depends on certain DLC/mods installed, or as an "off condition" - for example, if the player destroys the Brotherhood they probably shouldn't be using Brotherhood units any longer. For giving access to things in response to actions the player takes in place, you'll likey want to use the Unlock System to trigger them instead.
This group determines how this UnitType will integrate with the settlement system, as well as the viable roles Soldiers with this type can use.
bAllowAsPersonalGuard: If true, this UnitType can be brought as part of the player's Personal Guards.
At the time of this writing, Personal Guards are not implemented yet, but their intention is to act as a squad of pseudo companions the player can issue bulk commands to.
bCanBeGuard: If true, this UnitType can be assigned to the Guard role.
bCanBePatrol: If true, this UnitType can be assigned to the Patrol role.
bCanBeSupport: If true, this UnitType can be assigned to the Support role.
bCanBeWarrior: If true, this UnitType can be assigned to the Warrior role.
If all of the bCanBe properties are set to false, the NPC will be given the iDefaultClassIndex. If this is invalid, they will be assigned the Civilian role.
bRequiresBed: If false, this UnitType can be recruited even if there aren't any empty beds available at an Outpost. Note that in this scenario, you will need to configure iMaxPerGame or iMaxPerOutpost to prevent the player from over-recruiting and breaking their game with too many NPCs.
fFoodRequired: Overrides the amount of food needed by NPCs of this UnitType. If this is not set, the default of 1 will be used.
fWaterRequired: Overrides the amount of water needed by NPCs of this UnitType. If this is not set, the default of 1 will be used.
iDefenseModifier: The amount of Defense the unit should provide at the location they are stationed at. If set to -1, which is the default, the defense provided is tied to their SPECIAL Stats, the higher total SPECIAL stat pool, the higher the defense bonus.
The SPECIAL stat calculation for defense will always land between 1 and 20. With an NPC having 10s in all 7 SPECIALs getting the full bonus.
This is one of the few required groups, and define things used throughout the various systems of SS2.
DefaultOutfit: Under some circumstances, an NPC will change outfits, for example when they are captured. Having a DefaultOutfit ensures they can be restored to a baseline set of gear if there are no resources available to pay for equipping a Loadout, or the NPC lives in a location without an Armory - which by default is required to apply Loadout equipment.
iStrengthRating: This is used to rate the total power of a Military squad and should be a number between 1 and 20. With 1 being something like an untrained civilian or weak creature, and 20 being an extremely powerful unit like a Supermutant Behemoth or high-level Sentry Bot. This will require using your best judgement, if in doubt - look at existing UnitType records in SS2 to try and gauge the power level.
UnitKeyword: A unique Keyword form that all NPCs of this UnitType will be tagged with so they can be tracked easily.
The NPCLoadout script is used to define a series of equipment, perks, and abilities that are given to an NPC to alter them when they are assigned a UnitType, but also as they gain additional ranks.
Loadouts are Armor records which start as a copy of the SS2_Template_NPCLoadout record.
Loadouts will always be associated with a UnitType, and so we tend to name them accordingly so we can quickly pair them together at a glance.
Below we'll detail out the various script properties available.
This group defines AI packages, spells, and perks which can be used to give NPCs behaviors and abilities beyond what their Actor record might provide.
AIOverrideStampAlias: By default, all soldiers share a set of AI packages that react to their role and assignments. (Advanced) If your UnitType requires special AI packages, you can enter an Alias here with a custom package stack set up - be sure you check in Can Apply Data to Non-Aliased Refs on that alias, and the quest holding it should be of priority 43.
The priority 43 isn't a hard requirement, but will guarantee your packages end up higher in the stack than our default, while still allowing for other systems to have room in the priority stack to override yours when necessary. For example, SS2 has a Flee system which uses Aliases and must have room to override packages - so going all the way to 100 will make those sorts of systems not work with your UnitType.
CombatBuffs: These Spell records will be applied to NPCs when the Loadout is first equipped, and again just before any combat encounter, they will be removed when the Loadout is unequipped.
SpecialAbilities: These Perk records will be applied to the NPC when the loadout is equipped, and removed when unequipped.
These costs should generally be defined as Virtual Resources, so the player's settlement empire is paying for them. This can be done by selecting ActorValue as the Form Type on the Item, and selecting one of the ActorValue's WITHOUT _Daily that start with SS2_VirtualResource_ in the name.
In addition to defining items and the amount of each, you can also use the iIndex subfield to flag each cost entry with a category, this is used for mechanics that modify costs. Current valid entries for iIndex are: 0 = Caps, 1 = Rations (Food/Water), 2 = Scrap, 3 = Supplies.
AssaultCostOverride: This will change the cost used when sending the NPC with this Loadout on an Assault. Note that if this is set, it will not only override the default cost, but also the Unit's AssaultCostOverride field.
EquipCost: The cost to equip this Loadout. If none is defined, this Loadout will be free to equip.
UpkeepCostOverride: This will change the daily cost for having NPCs with this Loadout in the player's army, assuming the player has Soldier Upkeep Costs enabled. Note that if this is set, it will not only override the default cost, but also the Unit's UpkeepCostOverride field.
This group is used to display information to the player in various interfaces.
DescriptionMessage: This is a Message form with Message Box checked in that describes the role of this unit. It will often describe combat purpose and equipment, but can also include things like the creature type, or flavor information.
ShortDescriptionHolder: This is a MiscObject form with the Name field filled out with a very short description to remind the player what the UnitType's purpose is. Think of it as a short sentence summary of the DescriptionMessage information, the player can view the DescriptionMessage if they need all the details.
This section defines how NPCs using this loadout are equipped with various items.
AdditionalInventoryOnEquip: When this Loadout is applied, these items will be given to the NPC. When the Loadout is removed, these items are taken away. This is a great place for things like sidearms or flavor items the player can find in their inventory.
ArmorToEquip: The Outfit record equipped when this Loadout is applied. This Outfit record should include only armor items, not weapons. The armor can come from actual Armor records, or LeveledItem records, or a mix.
If the Loadout is removed, the NPC will be equipped with their new Loadout's ArmorToEquip property, or if not set, they will be given the UnitType's DefaultOutfit.
If you would like to support the Military Uniform feature, whereby the player can establish a uniform that's worn underneath armor, be sure to avoid items that occupy the Body and [U] slots in the Outfit record. You can view these on the Armor record in the center column which will highlight the slots in use.
ArmoryBonusItems_OneTime: These items will be given to the NPC the first time this Loadout is applied.
This field can hold up to three entries, each corresponding to the highest level Armory available at the NPCs home outpost. For example, if the NPC's home outpost has a level 1 Armory, they will receive the first entry.
ArmoryBonusItems_Restock: These items will be given to the NPC any time they Restock, which happens just before an Assault.
This field can hold up to three entries, each corresponding to the highest level Armory available at the NPCs home outpost. For example, if the NPC's home outpost has a level 1 Armory, they will receive the first entry.
ArmoryBonusItems_RestockIsOverride: If set to true, this will override the default Armory items SS2 provides for all units, which are a mix of Grenades and Stimpaks. If this is false, these items will be given in addition to the items SS2 provides by default from Armories.
bIgnoreUniform: If the ArmorToEquip Outfit includes items that fill the Body and/or Underarmor (ie. the [U] labeled slots), you can check this to prevent the player's chosen Military Uniform from being applied.
PowerArmor: If set, this PowerArmor will be spawned when the Loadout is applied and despawned when the Loadout is removed. During combat encounters, the NPC will attempt to enter and use it.
If the UnitType using this Loadout is not meant to be assigned to existing NPCs, but instead is a "Recruitable Only" unit, the better way to set up Power Armor is on the Inventory tab of the Actor record used as the UnitForm for the UnitType record this Loadout is for.
PowerArmorAlways: If checked, this NPC will remain in Power Armor permanently, not just in battles.
Due to the way AI packages are set up in settlements, NPCs will very frequently abandon their Power Armor in order to use furniture such as chairs and beds.
While not their own property group, weapons are handled a bit differently than other equipment and so deserve their own section. Due to the lack of means to natively equip or display the item provided by a LeveledItem record (which is commonly a desired thing to do with weapons in Loadouts - as LeveledItem records allow for dynamic use of injected weapons from mods, as well as variety in attachment), weapons are slightly more complicated to set up - or they can be incredibly simple - it really depends on how much randomization you want.
So the next few properties can be configured in a few different ways.
PrimaryWeapon: Enter the exact Weapon record you want the NPC to receive. It will still randomize slightly based on the ObjectTemplate that is configured on the Weapon record - but will always be that base weapon.
PrimaryWeapon: Enter a formlist of Weapon records you want the NPC to receive. The NPC will be given a random weapon from the formlist, which itself will be semi-randomized based on the ObjectTemplate.
PrimaryWeaponNameHolder: When using a formlist as the Weapon record, you'll need to create a Misc Object with the Name field describing this formlist and enter that into this property. For example, if you had a form list with a variety of Rifles, you might name the Misc Object "Various Rifles".
This way, when systems need to display a name for the weapon the NPC will receive if assigned this Loadout, the player will see text that makes sense. This is necessary because we can't display the name of Formlists in most interfaces.
PrimaryWeaponLL: A leveled list to be provided to the NPC. Ideally, this will be a list of weapons configured in such a way that an NPC will only ever receive one.
PrimaryWeapon: (Optional) If you create a Formlist with every possible weapon the PrimaryWeaponLL list could give, this field will augment the leveled list to give a better experience to the player in multiple ways:
PrimaryWeaponNameHolder: A Misc Object with the name field describing the potential weapons they could receive, just like filling out the field under Moderate Randomization.
This section includes options for how the loadout is used within the various systems.
iRankRequirement: This is used to flag the Loadout for which rank it should be used with. If left default, it's assumed any rank can use this.
This should generally only be left default if it's either the Rank 1 Loadout, or if the UnitType doesn't support multiple Loadouts - otherwise you'll find the system always applies the first Loadout in the UnitType's RankLoadouts array. The order of that array does NOT correspond to rank - it looks for this iRankRequirement property on the actual Loadout records.
iStrengthModifier: When this loadout is applied, the NPC will be rated as the UnitType's iStrengthRating, plus this modifier when determining the power level of the NPC.
Creating new Actor records is trickier than most of the other forms we've described so far. This subject aims to make it easier for you to create Actor records that will work well with the UnitType system.
To start, you'll want to start with the Actor record SS2_C3_UnitActor_Template as either the base you duplicate, or your reference point to compare to whichever NPC record you end up duplicating as your base. Below will describe the various tabs that have been set on this template and why, as well as things you might want to change to various effect.
This is the data on the left side of the actor record that is always visible, regardless of which tab you are on.
Name: This is the name the NPC will have in-game if the player speaks to them, gets close to them, or targets them in VATS.
Checkboxes: Most of these don’t matter for the soldier system, so we'll address the ones that you absolutely should not check in, or that have something important to know about them.
Respawn: Do not check. This could cause the NPC to continuously re-appear when the cell it was spawned in resets.
Unique: Do not check. Since the system will be spawning these, it won't be true and will cause problems with scripts that rely on this field to determine whether they are dealing with a named character or not.
Is Ghost: Do not check. This would make the NPC unable to be attacked, which would break assault objectives.
Invulnerable: Do not check. This will make it so the unit can’t be defeated in an assault or raid which would break the objectives.
No Activation/Hellos: Do not check. This would prevent the Manage Soldier menu from working.
Forced Loc Ref Type: Do not set. SS2 makes heavy use of the LocRefType system. Any spawned NPC with this set in the editor cannot have their LocRefType changed at runtime which would cause a lot of problems with SS2 systems.
Scripts: While not required, the system works a lot more reliably if the NPCs involved have the workshopnpcscript on them. If you do add it, you'll want to set the following properties:
WorkshopParent: This just let’s the script communicate with the settlement system and is the only mandatory property. There is only one option to set here, so select it.
bAllowCaravan: If this unit would be ok to let the player use as a provisioner - which would probably be most, check this in.
bAllowMove: This allows the unit to be moved between outposts like a settler can be moved between settlements with the workshop mode Move command. This should be checked in for any non-Virtual unit.
bCommandable: This allows the player to issue commands to the unit and should likely be checked in for most units.
If this is a human or other race with varied faces, you will almost certainly want the traits to be templated, otherwise every single one of these soldiers will have the exact same face, gender, and voice (We'll get into Templates in a section further down). For many non-humanoid races, this screen can be manually configured.
None of these fields will impact the soldier system, other than Race - which is important for UnitTypes/Loadout records which are generally tied to equipment, and equipment is almost always race dependent.
This determines the level and various stats the NPC should have. This is a place where you will very likely want a template to do the work - as those can use leveled lists to create a series of different level versions of actors that become increasingly more powerful as the player and zone they are spawned in becomes more powerful.
If you have a special case, such as a unit that needs very specific stats, or one where there isn’t a suitable vanilla leveled list template to tap into, read on to determine how to use this screen. The Stats set up for the Template is the same as that configured for a generic NPC, such as the Settlers in random encounters that can't be recruited.
Level: The primary change this will cause, is for the health to scale up, though it also impacts whether or not the player sees a skull when in combat with this actor.
PC Level Mult: This will ensure the npc is always at the player’s level multiplied by whatever you type in the Level text box. For example, if you enter 1 in the Level box (the default value), the NPCs level will be the same as the player - if you set it to 1.5 it will be 50% higher level than the player. When set, you can also change the Calc Min and Calc Max to determine the lowest and highest level an NPC can be when using the PC Level Mult.
Auto calc stats: When checked the NPCs stats such as health will be automatically boosted based on the level of the NPC. Turning this off will effectively make the level not impact any other stats and become a sort of meaningless number.
Base Actor Values, despite their name, are actually modifiers to those stats. The true starting point of the stats is the Class. The Class sets a baseline set of stats for the NPC, the numbers defined in the class are applied, and any of the values set in the Base Actor Values section are added to the number defined in the class.
The final values the NPC will have in game can be seen near the bottom of this screen, in the Actor Value Report section.
One option you have to regain direct control is to set the class to ZeroSPECIALclass, which effectively blanks out the base stats for the NPC. If you do this, be absolutely certain you have defined values for SPECIAL stats in the Base Actor Values screen or you could end up with some very weak NPCs.
The assumption is you’d be duplicating some actor record to start and will need to modify it. The first thing you’ll want to do is update the Templates tab.
Any tab you want to change data on from the template, uncheck the Use checkbox on this screen. Wait until the check actually disappears before doing anything else - if you try and click multiple checkboxes quickly, or try and mess with dropdowns or other tabs before this finishes - the CK can crash.
In general know that you can’t just use any record with any template, many of them just won’t work and so there are often specific records designed for use as templated.
Any template you used will grey out the selections for that NPC, effectively delegating their controls to the corresponding template record.
Traits are the most likely template where you’ll be using a vanilla template. There are a fair number of templates that are set up specifically for use in this. If you look for ones with “Face” in the list, you’ll be in a good spot. A very good one to use for generic human faces is LCharWorkshopNPC, which has a large variety of faces and is commonly injected into by mods to expand the pool.
The others you will probably not use as much, but each tab's description in this document might offer you an exception.
Generally you'll want no Factions predefined here, as the system would like to be able to spawn these Units for any army and apply Factions that trigger combat on the fly based on who the NPC needs to be hostile too. This is especially important for units the player might recruit, which may have PlayerFaction flagged as an enemy in some of the vanilla faction records.
The exception will be if you need to give them a special faction for dialogue purposes. If you cloned a default record and you see any factions with dialogue in the name, you should likely keep those, but delete any other factions found on this screen.
This tab is primarily used for dialogue purposes and likely won't be useful for anything related to the UnitType system.
Keywords can dictate a lot of behavior in Fallout 4. Below are some of the keywords you should include, or might want to include on your Actor records.
SS2_C3_Tag_ArmyUnit: SS2 uses this to quickly distinguish actors that were explicitly made for this system, versus vanilla units.
SS2_Tag_UnitType_: The unique keyword created for the UnitKeyword field of the UnitType record should be applied here.
IMPORTANT: If you duplicated the UnitActor_Template to start, remove the keyword SS2_Tag_UnitType_Raider. This was there as a reminder to include a UnitType keyword.
AO_Type_WorkshopAlarm: This should be on most units, it will make them rush to the aid of the vanilla workshop siren system.
Anim Archtype: There are a series of keywords that start with AnimArchetype, and AnimFaceArchetype - these change the animation style and resting facial animation state of these NPCs. Only include one of each type if at all.
Note that the UnitActor_Template has one of these included that you may wish to remove.
usePowerArmorFrame: These determine which power armor frame to render if the NPC is using just a power armor frame, or if pieces get destroyed revealing the frame underneath. In the power armor frames there are small gaps and holes where it reveals the NPCs under armor. Since the skeleton is different, the game can’t display the actual armor being worn and so instead shows a preset bit of armor. For example, usePowerArmorFrameVault would make it appear the person in the PA is wearing a Vault Suit underneath. For most non-faction NPCs, the usePowerArmorFrameRaider is generally what is used, or nothing at all.
This can be overwritten by certain pieces of armor which can apply a replacement one of these keywords - so consider this a fallback. Also note, the UnitActor_Template has one of these included that you may wish to remove.
SS2_Tag_StatsRolled: By default, SS2 rolls the stats of new NPCs added to a settlement so that they are fairly low. For any basic recruit type units, this behavior is what we should maintain.
For non-recruit type units though, this can result in NPCs being rebalanced. To prevent re-rolling of stats on other soldier actors, add this keyword to basically trick SS2 into believing it already rolled the stats and doesn’t need to do so again.
This tab largely determines how the NPC will react to other NPCs it has no Faction relationship with.
Aggression: This should always be set to Aggressive unless you have a very specific reason not to. Aggressive means the NPC will not attack unless an explicit enemy is near them. (Explicit enemy as in an NPC with an enemy faction record, or an NPC that begins attacking them.)
Confidence: In most cases, this should be set to Foolhardy, which means the NPC won’t retreat due to losing health or facing strong opponents. We have a retreat system built into SS2 to make them retreat when necessary, so placing them on Foolhardy ensures they aren’t fighting our rules.
Assistance: Helps Allies is what you’d generally set this to, this will ensure as we dynamically adjust factions, they will fight for the correct team automatically and help people in their army.
Morality: Set this to No Crime to avoid them randomly deciding to aggro the player if the player commits a crime in their vicinity. They will still aggro if you commit a crime against them - such as stealing from them directly, or getting into combat with an ally, but this will prevent the player accidentally being shunned from their own army if they ever use this unit.
Aggro Radius Behavior: This should almost always be turned off - it is usually only used by non-workshop turrets.
Combat Style: This determines what unit they fight like in combat. If you want to create a custom combat style, the record type is Miscellaneous > CombatStyle and allows for numerically customizing how they prioritize various things in combat. The best explanation of this system is on the Skyrim Ck website: https://www.creationkit.com/index.php?title=Combat_Style though some bits may not translate perfectly to FO4 and experimentation or reverse engineering from existing styles Bethesda defined will be necessary.
99% of the time, the AI of soldiers in our system will be controlled by the settlement system, or the assault system, so the first section of this screen basically doesn’t matter - as it defines fallback AI packages if no other package is available from an alias (aliases being how we tend to deliver packages because they override any leftover packages on individual actors) or quest scene. So you can generally leave the AI Package List empty.
The Default Package List and Combat Override Package List should generally be left at whatever they were on the actor record you started with if the actor is something atypical like a creature or Vertibird. For most humanoid soldiers, these should be set to DefaultMasterPackageList, and DefaultCombatMasterPackageList - that will ensure the other 1% of time our packages aren’t in play, the NPCs act like most players would expect.
This screen determines the starting inventory of the units in question.
Default Outfit: Since loadouts will be in use most of the time, the Default Outfit is generally just a fallback in case the loadout fails to apply, or the loadout in question doesn’t have an outfit record. An outfit can consist of specific armor pieces, as well as leveled lists, so is hugely advantageous for creating varied looks.
Power Armor Furniture: While SS2 has a dynamic system for providing power armor, the game is notoriously unreliable about providing power armor for NPCs at run time. So it’s generally best to make Power Armored units a separate type of unit with this field set to ensure they are always in it. Note that Power Armor furniture can be set up to use leveled lists for varied suits.
Inventory: This determines default items the NPC will receive. Many enemies have a great starting set to give them some random junk and pocket change, as well as to react to player perks - so a good idea to use one of those as a starting list.
This is something that will most likely be coming from your Loadouts, as we can provide similar effects via the CombatBuffs and SpecialAbilities properties on those, but if you need to add something that makes the actor themselves have an effect, regardless of loadout - this would be the place to do it.
Spells and perks are generally the same thing, but they use the term Spells here to mean things people cast - despite the name, it doesn’t mean magic. Any sort of aura or projectile not coming from a gun is probably coming from a spell record.
The remaining tabs have no direct impact on the SS2 UnitType system and so won't be covered here. It's rare you would need to edit any of those in general unless creating unique creatures or NPCs.
In patch 3.1.0, the ability for players to define a Military Uniform was introduced. This allows for applying a base underarmor record to all soldiers for free, to give them a sort of shared look.
These start as a copy of the SS2_UniformSelector_Template Armor record. These special records aren't directly equipped, but instead define which Armor records are equipped - these are used as selectors from the Uniform selection interface.
Before you start defining a uniform record, you'll want to find the Armor record you'd like to offer support for. Most of the base game vanilla Armor are supported by default in SS2, so if you are adding anything here, it would presumably coming from DLC or another mod.
The ideal uniform armors are using the 33- BODY, and 36 through 40 [U] under armor slots, with all other slots left empty. Anything else will intend to conflict with the Outfit records set by Loadouts and thus remove the armor added by those Loadouts.
Name: This field determines what the player sees in the interface to choose from.
World Model: This is what the player will have available as a preview model.
The Uniform records have a script SimSettlementsV2:Armors:Uniform applied. Below are the properties and how you set them.
BaseRaceUnderarmorMaps: This is used to map Armor records to the appropriate race(s). This allows for using a single Uniform record that ties together multiple Armor records one for each race the Uniform can support.
Each BaseRaceUnderarmorMaps entry consists of two fields:
RaceForm: This should point to the Race the corresponding Underarmor is for. If this is left blank, it's assumed to be for the most common 4 races: Human, Ghoul, SynthGen1, and SynthGen2 - so this can be used as a shorthand to save having to enter those 4 races independently.
Underarmor: This should point to the Armor record the NPC should be equipped with.
RankedVersions: (Optional) Uniforms can be set up in a way that each rank the soldier gets a different one. This could be useful for a Uniform with a rank insignia that changes as the NPC ranks up. To set this up, you'd configure this property ONLY for the rank 1 version of the uniform, and it would point to the Ranks 2 through 5 uniform records, in order.
In otherwords, setup all 5 uniform records without this field, then return to the Rank 1 uniform record and set this property to point at the other 4.
You now know about the various record types involved in making soldiers tick. The last piece of the puzzle is getting all of these records you create into the SS2 system.
For that we use the typical SS2 registration system. Below are a list of the FLID keywords you may want to inject to:
If you are unfamiliar with how to inject content into SS2, it's highly recommend you go through the Your First Addon tutorial, which will teach the pattern used throughout the mod for content injection.
SS2_FLID_NPCUnitTypes: All UnitTypes should be registered targeting this, whether they are for the player or NPC army use.
SS2_FLID_NPCUnitTypes_PlayerUnlocked: Any UnitTypes the player should have immediate access to should be registered targeting this. This does not bypass the PlayerArmyUseRequirements, so you can still set that to limit when the unit is available.
If you would like to trigger a unit to be available to the player via the Unlock System, use the RegisterForms field on the Unlockable, targeting two lists: SS2_C3_AllUnitTypes and SS2_C3_PlayerUnlockedUnitTypes.
SS2_FLID_SoldierRanks: Any new SoldierRanks you created should be registered here.
SS2_FLID_SoldierRanks_PlayerUnlocked: Any new SolderRanks you created that the player should be allowed to choose from when naming the ranks of their own army should be registered targeting this.
SS2_FLID_Uniforms: Any new Uniform records created should be registered targeting this.