The basics of creating new units are fairly easy and fast, but alien for someone just starting modding. While there are already a few unit creation guides out there (including Sebidee's, which I will link below) there are often issues with them being out of date or (imo) laid out confusingly, and I have a few other guides I'd like to do that build off of this, custom lords and skills and such, so I figured I'd start out the series with a simple unit creation guide.

You will only really NEED one tool - Rusted Pack File Manager[github.com], hereafter referred to as RPFM. It's basically a better and actively updated version of the classic Pack File Manager (PFM) with a lot of useful tools like dependency checkers and MyMod functionality that I mostly won't go heavily into here.

The one thing I will stress is to use the Diagnostics Tool heavily; if it isn't already on, View->Toggle Diagnostics Window.

Also make sure that your Total War Warhammer game is correctly linked in Packfile->Preferences, as well as that going to Game Selected and ensuring it's set to Warhammer 2. Diagnostics tool will catch most simple errors for you. You will need to generate a dependencies cache file (special stuff->warhammer 2-> Generate Dependencies Cache), which requires the TWW2 assembly kit to be installed.

I also suggest having two instances of RPFM open at once when modding, one opening the Data file to compare with vanilla tables and one for your mod. I usually keep a notepad file open as well with just the unit key so I can copy-paste it easily.

As one final note - you don't HAVE to follow the exact order I did this guide in. Many things can be done in any order, though you will often run into red dependencies temporarily if you do stuff in a weird order. I tried to lay everything out in the way I found most natural and easy to do, but if you find you REALLY like doing main_units before land_units... suit yaself.

While I will go down the list and explain what to do with each, I'm going to share my shortform list of tables and content for unit creation; once you get comfortable with unit modding you'll generally only need this rather than the full guide. If this is your first time modding though, I highly recommend going through the guide part by part so you don't miss important information, like which of these is a table, which is an image, which is a mesh, what the hell is a loc file, etc.

Basic Tables
land_units
main_units
ui_unit_bullet_point_unit_overrides
unit_description_short_texts
unit_set_to_unit_junctions
units_to_groupings_military_permissions

Visual Stuff
variants
unit_variants
variantmeshdefinitions
unit icon

Utility Tables
units_custom_battle_permissions
cdir_military_generator_unit_qualities
culture_to_battle_animation
building_units_allowed

Localization
land_units.loc
unit_description_short_texts.loc

First things first, we're going to create a new packfile (Ctrl-N). This gives us a blank pack with no tables or name. If this is your first mod, I would suggest saving it now, NOT in the data folder, with a simple name. There are a lot of different naming conventions out there; some people like prefacing their stuff with their username, some just name everything after the mod's name, whatever. Ideally you do want it to be unique so it doesn't run into incompatibility issues (don't name it mod.pack lmao).

Note that you can muck with mod order by adding characters to the start, it's common to see packs with ! or !!!!! at the start to ensure they load first. I would not recommend doing this unless you know exactly what you're doing, it's more of a tool for startpos mods and other major overhauls that really want to be loaded first; for most purposes something basic will do just fine.

While you may not find this works for you, I personally use the same key as much as possible throughout unit creation - if I name a land unit crys_skinwolves, you had damn well better believe the unit variant will be named crys_skinwolves, the main unit will be called that, etc etc. I just find it helps keep things simple, especially when you get into creating agents (lords/heroes) and start needing to attach campaign art and skill sets and all that jazz, and it's just REALLY nice to just have to copy-paste "chs_styrbjorn" instead of remembering 20 different things.

There are two ways to go about adding tables to your mod, both perfectly valid.

• Right clicking on the packfile->add->add from packfile->navigate to Steam\steamapps\common\Total War WARHAMMER II\data->open data.pack->open the DB folder->doubleclick on the tables you want to add, then delete all entries in the table and rename it
  
• Right clicking on the packfile->create->create DB and fill it out

For simple DB editing purposes, the latter is infinitely faster, easier, and simpler, with the added benefit of letting you name the table and not having to clean it out. However, it is good to know the former because for some purposes, like variants, you will need to use that approach, though for them you would generally go to variants.pack or variants_2.pack instead of data.pack.

If you do add a db table the first way for whatever reason, an easy way to clean it out is to use Special Stuff->Warhammer 2->Optimize Packfile.

For now, let's just create a new table. The bottom box lets you filter results; type in "land_units", then open the dropdown list - there's only 4 tables there; "land_units" is the one you care about. Add it and name it whatever you like, the game doesn't care as long as it doesn't clash with vanilla table names or other mod tables. Now rightclick and select "add row", and... oh jesus lord what the hell are all these things?!

Fret not, you don't actually have to know all of them! This is where having a second window of RPFM open in the data version of the table is useful. Just copy the row from the closest vanilla unit to get us started. At the bottom right is a dropdown menu to change what to filter by; change to "key" and then type in the unit name you want to copy from, which may take a few tries depending on CA's weird naming conventions. In general, only type in 1 word, like "champions" instead of messing around trying to figure out how CA decided to name Marauder Champions with Great Weapons (wh_dlc08_nor_inf_marauder_champions_1 as it happens).

Some important notes;

• Key is incredibly important - it should be unique and not shared with any mod or vanilla unit. I recommend NOT using CA conventions, keep it simple; if you're making Chaos Fimir then chs_fimir is a decent start, though for compatibility you may want to add more text, say crys_chs_fimir. Whatever you use, save it now and keep it handy somewhere else, you'll be copy-pasting that key a lot in this guide.
  
• When in doubt, just use the entry from the closest vanilla unit. Good rule of thumb. You don't have to know what the heck dr2_hydra is, but if the vanilla war hydra uses it as an animation, your budget hydra probably should too.
  
• "Man Entity" references the battle_entities table, which controls unit speed, mass, resistance to knockback, etc. Many vanilla entities are shared between many units; if you want to mess around I'd suggest making custom entities.
  
• Primary Melee/Missile weapons are fairly self explanatory in what they do; making new melee weapons is almost trivially easy, new missile weapons take some extra tables for projectile stuff but isn't that hard either.
  
• New attribute Groups have to be defined in unit_attribute_groups and attached to actual attributes in unit_attributes_to_groups.
  
• Note that you have to either reference vanilla armor/shield values or define new ones in their respective tables - you can't just fill in wh2_main_leather_88 and expect it to work.
  
• Damage mod [whatever] is the unit's resistance to that type of damage. Flame can be negative, the rest can't as far as I can tell.

Similar to how you added the land_units table, do the same for main_units and copy the closest vanilla unit over.

As a general rule of thumb, the Main Units table is more focused on out of battle stuff - unit costs, caps in campaign or multiplayer, additional building requirements, etc.

• Change the "unit" field to your personal key, ideally the same one you used for your land unit.
  
• Additional Building Requirement is used if you want the player to have a secondary building to make the unit, and is left blank otherwise. References the building_levels table if needed.
  
• Campaign Cap is -1 for most units, but can be limited as desired if you only want a faction to be able to make, say, 6 Steam Tanks total
  
• Land Unit is a direct reference to the land_units table entry you just filled out, make sure you have your unit's key there.
  
• Unique Index is deprecated - it doesn't actually HAVE to be unique. I'd still suggest getting in the habit of making it unique since almost every other table with IDs does require them to be unique.
  
• Ui Unit Group Land/Naval can be customized if you make a new one in UI Unit Groupings, but using vanilla ones is much easier starting off.

Despite having an utterly terrifying name, this is just the table that assigns those little green/red text lines on the unit card. Note that these DO NOT HAVE ANY MECHANICAL EFFECT, they're solely visual, but you still want to make them as accurate as possible since they're the #1 way you can communicate to users what your unit actually does. You can make custom ones as well but again, that gets into loc editing and if this is your first unit it's probably easiest just to copy and paste from the closest vanilla unit.

Super simple table, just put your unit's key (chs_fimir or whatever) here. This is the stuff that occasionally pops up in events when you recruit a unit, just flavor text.

Ah, unit sets, love of my life. Much maligned and little understood, unit sets are a huge part of how your unit interacts with campaign mechanics; they define what technology, lord skills, faction effects, etc. work on them. If you're just making, say, tier 4 Empire Halberdiers you can just copy the same unit set junctions from the empire version; new units may take a little more work and especially if you have custom skills targeting specifically them you may need to define some additional unit sets (explained below) as well. Kinda as usual, Unit Record references the main_units key. As usual, this is ezpz if you just use the same key for everything LOL.

Unit Set can be a bit confusing at times, but as a loose rule of thumb, there are some main types of groups to look out for;

• Oftentimes there's a faction_all set, ex. chs_all, that is used for some factionwide effects
  
• Some techs and skills may involve unique sets, like empire_infantry or chs_manticores. Try to match up against vanilla units as relevant.
  
• The format varies by faction, but most units will be in a set of 2-4 units with a name vaguely similar to wh2_dlc11_emp_spearmen_swordsmen_flagellants_halberdiers or something along those lines. That's for the basic red line skill that buffs those unit types. If you put your new unit in that set, they will benefit from those redline buffs.
  
• Similarly, there's usually a set with "vet" somewhere in the name, ex. wh2_dlc11_chs_vets_chariots_chaos_knights_dragon_ogres_warhounds_manticore. That is for the rank 7+ locked skills.

You can generally ignore caste, category, and class, and unless you WANT to exclude a unit from a set, leave "exclude" unchecked too.

As a general rule of thumb, most vanilla units are in 4-6 unit sets.

Note that if you make a custom unit set (using the unit_sets table), you can replicate the vanilla rank 7+ groups by checking "use unit EXP level range" and defining the inclusive range, say from 7-9 or 4-9 or whatever. Otherwise leave that unchecked.

This table is quite simple and basically just tells the game "yes, this is a Chaos unit and should be accessible to factions using the Chaos military group". You'll need other tables to actually recruit the unit in campaign for example, this is just a prerequisite.

This table is pretty simple; aside from starting to attach variants together (more on that soon) it also lets you scale your units up or down as desired. "Scale" lets you change the side of non-mounted entities as desired, while "Scale Variation" is how much randomization there is within a unit, often 0.05 in vanilla so not everyone is exactly the same height.

Note that the actual physical height of the unit, for purposes of being hit by artillery etc, is defined in battle_entities, NOT here, this is just visual.

Tech folder can be left blank in almost all situations - it's only needed if you're making a custom mount which is A. complex as hell and B. WAY out of the scope of this guide.

This table just links units to variants, cards, etc. I just use the same key for every column to keep things simple.

This is where things get tricky. So the basic idea is that you are going to import a variantmeshdefinition from one of the variants.pack files in the actual data folder, then rename it for your unit and customize what's in it. While we usually use create -> create db, in this case we usually want to use add -> add from packfile and rip off something from variants.pack or variants_2.pack, maybe campaign_variants/campaign_variants_2. They're pretty scattered, it may take some looking around.

The complexity of this depends a lot on the unit and how many moving parts there are, but as some general commentary;

• Any given variantmeshdefinition is divided into multiple slots, usually stuff like "body" and "head" and "weapon 1".
  
• If a given slot has multiple variant meshes inside it, the game will randomly pick one for each model of the unit. Five entries - five possible visuals for that slot. On lower graphics settings the game only cares about the first three, so keep that in mind.
  
• Weapons have a very specific set of hooks that must be done correctly. As a simple version;
  
• Dual wielders define their weapons in slots 2 and 5 individually
  
• Two-handed weapons go in slot 1
  
• Shields go in the shield slot, huge surprise
  
• Units with multiple weapon types (ex. Marauder Hunters, Darkshards, etc) vary WILDLY in where each weapon is and should generally be referenced from vanilla

Beyond that, different models have very different setups - for example a vanilla variantmeshdefinition may or may not have a randomized head slot or just the one. You can mess around and do some seriously cool stuff but be aware that a lot of stuff is built specifically for one model or animation and can be hard to muck with.

As usual, just copy-pasting from a vanilla unit's definition is a safe start.

I already mentioned this above, but to repeat, make sure to rename the file to fit whatever you set up in the variants db table so the game knows to link this definition to your unit.

Unit icons are the visuals on the bottom bar of campaign map or in battle. You can find vanilla ones in data.pack -> ui/units/icons. Yours should follow the same structure.

Depending on what your unit is, you can just steal an existing vanilla one wholesale (ex. if you're giving Fimir to the Warriors of Chaos), or edit it to look a bit different, or use an entirely new image. The only real rules here are that it should be 60x130 and NOT use any copyrighted material from other people that isn't warhammer related.

Some people are wizards with art and can customize an existing icon in photoshop/gimp to look amazing, others of us are dain bramaged and stuck taking ingame screenshots of the unit then doing some basic editing to focus on the unit and get them down to 60x130, then using "add->add file" to get that icon into the correct folder layout.

While creating custom lords is out of the scope of this guide and will be focused on later in the series, I will note that they actually store their icon in a different place, specifically ui/portraits/units.

This is a completely optional table but one that is very useful for testing units quickly. Overall it's generally very self explanatory, just define the faction(s) that can get this unit and link the unit key.

If you're making a custom lord, you may have to fill out some of the columns on the right; note that 'General Portrait' should be the full path rather than just the name, ex. "UI/Portraits/Portholes/chs_saenathra.png". Otherwise ignore this paragraph.

This table is required for the AI to recruit your unit - just rip off a similar vanilla unit.

What this table actually does beyond that is the subject of much debate, and until CA clarifies it for sure we may not know for sure.

This table is only necessary if you're using a cross culture animation - for example, a Wood Elf animation for a Norscan unit. Some factions share cultures with similar ones (ex. Norsca and Chaos don't need to worry about this, the Norscan Berserker animation will work fine on a custom Chosen unit) but if you're trying to give Bretonnians a War Hydra unit, you will need to use this.

The "Man Animation" column in land_units is the animation you'll want to put here.

This table allows your unit to be recruited in campaign, using the cost and recruit time values designated in main_units. Pretty self explanatory overall, just note that you need a unique string of numbers for the Key and that EACH level of a building needs a separate entry. For example, if you want to add your new custom Empire Swordsmen to all levels of the Chaos Warrior building (why????), you have the unit key, ex. "emp_my_awesome_swordsmen", and have three entries for "wh_main_horde_chaos_warriors_1" "wh_main_horde_chaos_warriors_2" "wh_main_horde_chaos_warriors_3" that each attach to your swordsmen.

If you don't do this and only define it at say, "wh_main_horde_chaos_warriors_1", then while the chaos warrior building is at rank 1 you'll be able to recruit your new unit there, but as soon as it upgrades to 2 or 3 you'll permanently lose access to recruiting your unit.

"But Crysbore, you spelled the table wrong!" I ♥♥♥♥♥♥♥ wish I did dude, nope, that's the official CA name for the table, didn't even notice 'til Bastilean pointed it out to me.

Thankfully aside from spelling this is another simple and easy table - you just link your land unit (you DO remember your key, right?) to a unit ability - you can either compare across in the vanilla version of this table for a common one (ex. Frenzy) or check unit_abilities if you want to add another ability.

You could load up your mod now and see the unit ingame, assuming you didn't muck anything up, but you'll quickly notice there's a problem - the unit's name, description, and (if you made any) ui unit groupings etc. are all blank! That's because you need localization files, which can be found in the "local_en" file in the data folder. You add them the same way you do a normal table, importing from that file and purging the unclean entries, and same as with DB you'll want a second instance of RPFM open to compare.

This may look ugly at first, but is very easy to setup thankfully!

So the first important thing to know is that your Key will ALWAYS start the same way: "land_units_onscreen_name_". Then you append your unit's key. So if your unit is "crys_naked_skinwolves", you end up with a key that looks like "land_units_onscreen_name_crys_naked_skinwolves". Kinda long and intimidating but whatever.

For the Text column, just put in the name you want to show up. "Unarmored Skinwolves" or whatever.

You remember about 80,000 years ago when we added that one super small table about unit descriptions? This is where you write the actual description.

Same as with the last .loc, you preface your unit key with "unit_description_short_texts_text_"

I don't think there's TECHNICALLY any length cap, I've seen some seriously gnarly long descriptions, but for practical reasons I'd suggest keeping it concise.

Unless you went crazy with customizing stuff you won't need any extra loc files for a generic unit, but if you're like me and can't stop with the verbal diarrhea, you may need to add more, like "ui_unit_groupings.loc" if you made a new UI group for your unit to add extra flavor text to them.

First thing you always do: after making sure that your preferences are set up correctly, look for red boxes! It's almost always the reason the game crashes or the unit doesn't work right, and even as an experienced modder you can still make dumbass mistakes and leave the "shield" column blank instead of "none". Speaking from experience on that one.

.loc files will almost never cause a crash (apparently there are a few edge cases with some tables) but in general, mucking up loc files will only lead to invisible text rather than crashes.

Variants USUALLY only make your unit invisible instead of crashing but it depends on what you mucked up there - be sure that you named the variantmeshdefinition correctly for example.

This is on many levels a deeply subjective and heavily mod reliant subject so I won't tell you what you have to do here, but as a few loose rules of thumb;

• I highly recommend using vanilla reference points for most numbers - if your unit is just a set of Fimir with, idk, shields, then price them around other Fimir, maybe a bit higher if they have all better stats, or similar if they have tradeoffs.
  
• Similar to the above - tradeoffs are fun! If your unit has incredibly powerful offense, making them squishy or short ranged can make up for it. If you're making 80 speed Irondrakes riding boars, strip off most of their armor. Maybe your new custom Hellcannon hits harder but fires slower.
  
• AP damage is a weird subject that not even CA seems to know exactly what to do with, given that they've been slowly buffing a number of duelist characters to have a much more AP heavy profile. As a general rule of thumb, if the unit doesn't have a good reason to be AP heavy, don't make them too AP heavy by default; almost all weapons have a healthy balance of AP or not, 99 ap damage and 1 normal can be a fun gimmick but if all your units look like that and have no downsides, they're probably OP.
  
• Balance is friggin' hard, and you shouldn't feel bad if you aren't sure about it initially! I'm by no means an expert myself, just try testing stuff and see how it feels in practice. Some ideas work out great, others don't.

This is my first TWW2 guide and I am under no illusions about myself being a flawless master of my craft - I am sure there are parts of this guide that will be confusing for newcomers where I accidentally used unnecessary lingo or forgot to explain what the heck to do. Please, let me know! Nicely if possible, I would greatly appreciate that part, but I am eager to improve the guide and constructive criticism is greatly appreciated.

If you are interested in how to turn a unit into a lord/hero, this follow-up guide covers that!

NOTE: this is a more conversational but complex section, not required for creating a new unit. Just something that has come up for me a number of times when modding so I figured I'd discuss it.

------

While the above steps are accurate for creating a new unit, there may be times in your modding career you don't actually need to do every single step here. For example, let's say you want to make Fimir recruitable by the Empire, or give the Lizardmen access to Empire artillery, or maybe you want to get even fancier with your mods - say you have a script that lets the Empire access Saurus Warriors if they make a Military Alliance with a Lizardman faction, but you only want them to get 4 Saurus Warriors instead of infinite, and you don't want to edit the base Saurus Warriors unit, AND you want the unit stats to stay compatible with Radious or SFO or whatever. How do?

Well, let's go with the easiest version - we'll just let the Lizardmen recruit Mortars.

As we discussed earlier in the guide, units_to_groupings_military_permissions is the obvious table to allow the Lizardmen to even see them, and building_units_allowed defines where they can be recruited from - just those two tables will generally work as long as the unit doesn't have an additional building requirement.

If you want them to get buffed by Lizardman redline skills, you can use unit_set_to_unit_junctions to sort that out, same as we talked about earlier.

------

Now let's get a little more complex. What if the unit has an Additional Building Requirement in main_units that we don't want to deal with? What if you want to only unlock 4 Saurus Warriors for the Empire, but you want it to be more-or-less compatible with overhauls that touch on stats? We can do this fairly simply with a main_unit clone, which is about 30% of the work of creating a new unit.

The basic idea is that you copy the vanilla main_unit you want, changing the key to your own, but leave the link to the vanilla land unit - that ensures that if SFO is on, your ported Saurus Warriors will still have that mod's crazy stats. They won't have the increased upkeep SFO is known for, but eh, if you care that much make a SFO version. But you can change important aspects of the main_unit, like building reqs, upkeep, and unit cap as desired WITHOUT borking the original.

In general, you'll probably need most or all 7 of these tables

main_units
ui_unit_bullet_point_unit_overrides
unit_set_to_unit_junctions
units_to_groupings_military_permissions
cdir_military_generator_unit_qualities
culture_to_battle_animation
building_units_allowed

Since variants, unit cards, etc. are linked to the land_unit key, you can just ignore them here - they'll use the vanilla ones.

You won't need this table for most units, but it can be useful if you want to lock a unit to a specific faction instead of a military group. If so, DO NOT add the unit to the units_to_groupings_military_permissions_tables table, that one 'beats' this table; ONLY add the unit to this table. Ingame, only the faction(s) you use here will be able to recruit the unit.

In vanilla, I think it's only used for RoR permissions; faction units are generally handled by script/special stuff (ex. Markus's imperial supply units) or unique buildings (ex. Wurrzag and savage orcs). But if you just want to add a unit to a single faction, this is definitely easier than a whole new building chain.

I cannot in good faith fail to link Sebidee's Complete Guide to Warhammer Unit Modding[www.twcenter.net], which is what got me into unit modding in the first place. It goes into a lot of detail on many things, and the dude is clearly VASTLY more skilled at the fancy pants art side of things than I am. I did not copy anything from it, but at the same time I feel that credit where credit is due.

I highly, highly, HIGHLY recommend the C&C Modding Discord[discord.gg]; there are a lot of very knowledgeable modders there who have helped me out greatly over time, and the community as a whole is pretty great. Modding tech 1-4 channels are where you ask questions, they don't always get answered, especially if it's about extra complex or poorly known stuff like startpos modding and the few people who are super knowledgeable about that aren't around, but in general it's helped me a ton.

I linked it above, but Rusted Pack File Manager[github.com] is incredibly valuable to all modding I do and I cannot recommend it highly enough, especially over the aging PFM that older guides often recommend. Nothing against PFM, it has its uses, but in general RPFM is just better on almost every level.