I'm gonna try to write up a simple faction guide because I never managed to find one when I was creating my mod, Factions Expanded. I'm in the boat of not liking the faction-making mods like ALIVE and Drongos (no shade to the authors, I just wanted a more fine control over my mod), so I went to the effort of learning how to do it manually. It took me a couple of years to figure it all out, so I hope this will help someone else only take one year at most. I'm only going to go over the basics in the interests of keeping things short; I'll show how to make a custom faction, two soldiers to go into it, and a group for them to be in, using existing assets from the base game (technically I used the Contact woodland stuff). But this can also be applied to using modded content, as long as you set those mods as required addons for yours.

I first wrote this for Reddit, but I decided to copy/paste it over here too. This one is gonna be the updated one if I need to fix or add anything, so don't rely on the Reddit copy.

First I'll go over what programs I use.

For editing all my config files, I use Notepad++[notepad-plus-plus.org], set to C++ language. Technically the language Arma uses isn't C++ but the syntax seems to work out.

For packing my folders into .pbo files, I use .pbo manager, which I found on github, but I lost the link (sorry). I think there's a couple different versions by a few different authors but they should all be able to pack folders into .pbos. I think there's a way to do it with the official tools too, but I never managed to figure it out.

I also use the Advanced Developer Tools mod, because it makes the config viewer much, much nicer to work with.

First thing you need is the structure of a mod, which I'll go over briefly.

This is the structure of your mod. The "@TAG_Sample_Mod" folder is what you upload to Steam Workshop. "addons" is the folder that contains your .pbo files (where data is stored), and "TAG_sampleFaction" is the folder that gets turned into said .pbo. You can have multiple .pbo files in your addons folder, I usually use one .pbo per faction, plus a core .pbo for shared data, for better organization.

The TAG part is important, especially if you plan to publish your mod (you should substitute your own tag wherever I'm using TAG, mine is TTU_ for example). See the OFPEC website[www.ofpec.com] for more info on this.

config.cpp is the most important file, it contains all of your config data, which defines everything in the mod, like soldiers, vehicles, groups, and weapons. We'll take a look at it now.

config.cpp is the center of your mod, it should always be saved directly into the folder that will become your .pbo. Everything config-related goes in here. There are methods to make this less messy than it sounds, which I'll go into later, but for now we'll focus on the first of our classes, CfgPatches[community.bistudio.com].


CfgPatches is what tells the game how and when to load your mod, and defines what other mods are required. The above example goes directly into config.cpp, at the very top is where I usually put it.

The classname, here "TAG_sampleMod_sampleFaction", is what your mod's config name will be, and it must be unique.

The name and author can be anything, they'll show up in the list of mods at the bottom of the main menu.

version and requiredVersion I just left as default, and never had any problems. You can find more info on them at the CfgPatches page I linked above if you want to be more thorough than I was.

the units[] array is important for making sure your units will show up in Zeus mode. All custom CfgVehicles entries (soldiers, cars, tanks, etc.) need to be added in here. You could also add in any custom weapons in the weapons[] array but I've never done this and didn't run into any problems yet (it's probably important if you're actually adding new weapons, just putting attachments on them means you can probably skip it). The entries I've added in this example are the soldiers I'll be creating in the guide, make sure your classnames match when you do this yourself.

requiredAddons[] is another important array because it tells the game what order to load your mod in. If you leave it blank, it might load your mod before another that is required, which can break things, or it might make your mod override something in the base game/mod that you're working with and break a vehicle turret or something. Any mods that your mod requires, you should enter them here, using their classnames defined in CfgPatches (the equivilent of TAG_sampleMod_sampleFaction for our mod).

If you're using Advanced Developer Tools, you can search up a classname of something required for your mod, and it will list the relevant CfgPatches entries at the bottom of the window. The "A3_Characters_F" I've shown in the screenshot is the addon that contains the base classes for your men I'll be going over later, so make sure to include it.

Now that we've defined our mod, we can add a custom faction and a soldier to go in it.

First thing, we'll make another entry into config.cpp to define our faction. There are two ways to do it, depending on if you're recreating an existing faction or making a totally new one.

For an existing faction, what I do is inherit off the one I'm remaking. This means all the data, like flag texture locations and side, are copied over into my faction, and any edits made to the base version will also carry over to mine. It also means that if an end-user uses a mod that edits factionClasses, the edits apply to your version of the faction too, for example the rank icons in ace3. Put this into your config.cpp, below the CfgPatches class:


Now, the way inheritence works is by defining an existing class (in this case BLU_F), and then telling the game to copy it over to a new class (in this case TAG_sampleFaction), and only change the entries that you define. You can see I define the original class first, then use a colon after my custom class to tell the game which one it's supposed to copy. Then I change the name and author, but everything else in that class will remain as it is in BLU_F, for example the flag texture location.

If you aren't creating a new faction, you can skip to the next step here.

If you want to define a new faction, it's simple, you just have to define a few extra things. This would go into the same place as the above example, replacing it:


The difference between flag and icon is that icon is what shows up on the scoreboard in sector missions, for example. The images should be .paa files, you can create them from .pngs using the texView 2 program, which you can find in Arma 3 Tools on Steam. Simply open the .png in the program, then "save as" and change the file extention to ".paa". You can use the same image for both the flag and icon if you want to, CUP does it and it seems to work out fine. The file path is defined relative to the .pbo file, structure is as follows:



priority is supposed to define how far up the list of factions your faction will appear in the editor, but it seems to be broken (or I just misunderstood what it does) since changing it has never had any noticable effect in my mod.

side defines what side your faction is. 0 is OPFOR, 1 is BLUFOR, 2 is GREENFOR and 3 is civilian. These numbers apply to pretty much every other instance of side entries in other classes, so it's worth remembering.

Once we have our faction, we should add a soldier to it. We'll make use of .hpp files now, to keep things neat, and avoid dumping thousands of lines of code into the config.cpp file. The way this works is pretty simple, you create a new file, call it anything you want with ".hpp" at the end, and then you can insert it into config.cpp (or even other .hpp files, you can nest them) by using
You can even put them in subfolders, as long as you define them in the #include, e.g.
for a file that could define your spec ops soldiers. Note that a semicolon is not required for these preprocessor commands, the ones that start with a #. The path always starts from the .pbo, the same folder that your config.cpp file is in.

The first thing to do is define some helpful macros I found on the BI wiki[community.bistudio.com] (that link also includes some more detailed info on encoding soldiers), and setting my includes.


I usually put this into a seperate .hpp file, and then #include it in config.cpp, but yours will probably be a lot shorter than mine so you can just put it directly into config.cpp if you prefer (I have a ridiculous amount of soldiers in my mod which leads to a ridiculous amount of .hpp files).

First are the macros. These are useful for saving space when defining your soldiers' magazines (it also works for items), and when creating backpacks. I'll explain these in more detail once we're actually using them to create a soldier.

Next are the inherits. These are the base classes that your new classes will copy from. I put these in a seperate .hpp file because, if you want to include vehicles, you may end up with a long list of classes to inherit. The game reads the config from top to bottom, so make sure inherits comes before anything that is inheriting. For now, you can just put your soldier's base class in here.

There are 3 base classes for soldiers I use. B_Soldier_base_F for BLUFOR, O_Soldier_base_F for OPFOR, and I_Soldier_base_F for GREENFOR. I'll be using the blufor one but the idea is the same for all three. Place whichever one you need into your "Inherits.hpp" file, for my example it would be:


Now, to make things organized, I'll make a folder based on some subfaction type, e.g. what camo they wear, or what year they're based on, or what type of unit they are. In this guide we'll go by camo, so I'll make a folder called "Woodland", and save a file there called "men.hpp". This file is where we'll make our soldier.

Note that the soldier's class goes into the CfgVehicles class. In Arma 3, a "vehicle" (as defined by config) seems to mean basically any object, from vehicles to soldiers to crates to buildings.

Inside the men.hpp file, enter your new soldier's class:


If you're not doing multiple camo variants, you could just put it directly into "men.hpp" without the folder, just remember to change the #include filepath in CfgVehicles accordingly. Assuming you are doing camo variants, this is what your mod should look like at this point (minus the images folder if you used inheritance on the faction class):

First, note the TAG in the classname, this is to prevent clashing with any existing soldiers or mods that the end-user might be playing with. Then you can define the rest as you wish. It's probably a good idea to at least include the faction and type of unit. Remember these have to all be unique, if you use a double the game won't load and you'll get a "classname already defined" error, and if you use one in use by the base game or another mod, you'll overwrite it, which can cause problems if you don't know what you're doing.

Next is author and displayName, which are pretty self-explanitory. The displayName shows up in 3DEN and Zeus editors. There's also the three scope entries, which define whether your unit should be hidden or not. 0 means completely hidden, 1 means hidden but can be spawned with scripts, 2 means shown. These entries define it for overall, the virtual arsenal, and zeus mode respectively.

Next is uniformClass, which defines what uniform the soldier will wear. Beware that most uniforms are side locked, and if you attempt to give, for example, CSAT Fatigues to a BLUFOR soldier, it won't work. There are ways around this, that involve changing the side-lock on the uniform, which I have decided to get into after all, see Extra Stuff 2 at the bottom.

What you'll want to enter here, and this also goes for the other equipment we'll be defining here, is the classname of the equipment. You can look them up online[community.bistudio.com], or see them by mousing over the equipment list in the Arsenal. ACE arsenal actually has a feature that lets you copy/paste classnames directly, which I highly recommend. As long as you don't include any actual ACE items in your loadouts, you won't have to list ACE as a required mod.

Next is camouflage, pretty self-explanitory. A lower number means better camo. BI numbers are 1.4 for a NATO rifleman, 0.6 for a NATO Spec Ops Scout, and 0.4 for a NATO sniper in full ghillie,

backpack defines what backpack the soldier wears, we'll go over this later. You can leave it as "" if you want no backpack.

Next is cost and threat[], which define how dangerous your soldier is. From what I understand, cost is how much weight an enemy will give your soldier when considering who to target, relative to other units' costs (higher number = more likely to choose him), and the threat[] array multiplies that number in the eyes of light vehicles (or maybe infantry, I'm not sure about this), heavy vehicles, and air vehicles respectively. The values BI used can vary a lot so I'll suggest you look some up in the config viewer instead of trying to list them here, but the basic rifleman for NATO is 100000 cost and 0.8, 0.1, 0.1 threat, as a baseline.

Next, editorSubcategory and role define the category the soldier appears in in the 3DEN editor (e.g. "Men", "Men (Woodland)", "Men (Special Forces)") and the respawn loadout screen respectively. You can find values for these if you search up CfgEditorSubcategories and CfgRoles in the config viewer. You could also try creating your own custom subcategories and roles if you want to, they're pretty simple so I won't go over them here, just copy what you see in the config viewer.

icon and picture define the small dot shape when you place a guy in 3DEN or Zeus, and the picture present in the squad bar in-game, respectively. Possible values for icon are iconMan, iconManLeader (one diagonal line), iconManOfficer (crossed diagonal lines), iconManMG, iconManAT, iconManMedic, iconManEngineer, iconManExplosive. Possible values for picture are pictureHeal, pictureRepair, pictureExplosive, or leaving it blank for most units. The nameSound and text- entries define what other units call your unit, e.g. AT soldier, machinegunner, both audibly and in the subtitle text. You can find a list of possible values here[community.bistudio.com]. The one in the example is just "rifleman", as in "Two - attack that rifleman".

faction is what faction your unit is in, obviously. You'll want to put in the classname of the faction you created in step 3 here.

Some additional entries that will likely be of interest are: attendant = 1; for setting a soldier to be a medic, engineer = 1; for setting a soldier to be able to repair vehicles, and canDeactivateMines = 1; for setting a soldier to be able to deactivate mines and explosives (obviously).

Now we get to the actual equipment. You'll notice each array is doubled with a "respawn" variant. I believe this is used for the respawn loadouts screen, but I've never tested it to confirm, so I just include them to be safe.

The weapons[] array defines weapons, which also includes binoculars, rangefinders, etc. I heard best practice is to do it in the order (primary > secondary > pistol > binos > throw > put), but I've messed with that order before and it had no noticable effects . The last two, throw and put, are very important to include in every soldier, because without them, you can't throw grenades or place explosives, and the only other way to acquire them is scripts. You can find weapon classnames in the Arsenal or on the BI wiki[community.bistudio.com], same as with uniforms. I'll go over how to add attachments later, or you can just use the attachment'd weapons BI already defined on the wiki.

magazines[] is where you define carried ammunition (classnames here[community.bistudio.com]), including throwables and explosives, although most explosives are better off in a backpack, in which case you don't want to include them here (I'll go over backpacks later). Here's where our macros come in; simply replace the "a" in the macro with the classname of the magazine, and it will multiply that magazine by the number, saving a ton of space and making your config way easier to read. If you want more than the macros define, you can either add two macros in the array, or try writing a new macro with more "a"s in it. Note that when you define your magazines for weapons here, one will be inserted into the gun, so spawning the guy with 9 mags means he'll have 1 in the gun and 8 in his uniform and vest. There's no way I know to force something to spawn in the vest or the uniform, it just fills up the uniform and then puts the rest in the vest. You also can't overload the uniform and vest; if you add too much stuff here, it just won't spawn at all, so keep in mind the storage limits on the equipment you're using.

items[] defines items like FirstAidKits, Toolkits, and Medikits. You could also put weapon attachments here, if you wanted them to be stored in the uniform or vest, or NVGs if you want them to be stored but not worn. Even things like helmets or hats can go here, as long as they can be stored in a vest or uniform.

linkedItems[] defines items that go into slots. This means, helmet, vest, the items along the bottom like the map and compass, and NVGs. You can also define glasses here if you want to force them on, e.g. a balaclava or combat goggles.

Lastly, we have genericNames, which defines the names of the soldiers (e.g. James Walsh, John Jackson), and the identityTypes[] array, which defines the language and head models your soldier will use, and what goggles they'll be randomly assigned. Best way to get values for these is to inspect the config entry of a soldier who has the traits you're looking for.

At this point you should be able to pack the mod into a .pbo, load it up, and see your new soldier in the 3DEN editor.

Next we'll use your new soldier as a base to create another one. This time, an AT guy. Make sure this goes underneath the first soldier, so the game knows what a "TAG_SampleFaction_Rifleman_Woodland" is:


As you can see, using your new soldier as a base class saves a lot of space, because we don't have to re-define the entries we don't want to change, like the faction, author, and linkedItems. And as we can see, this guy needs a backpack to carry his rockets, so I'll go over that next.

Creating a backpack is pretty easy. First, create a new "backpacks.hpp" file, and #include it just above the "men.hpp" file, but below the "inherits.hpp". Next, go back to "inherits.hpp" and declare the class of the backpack you want to use, in this case I'll go with the woodland assault pack to match his camo:


Now, in the backpacks.hpp file, we can define our backpack:


With the macros from above, it's very simple. Notice we're using the second set of macros for backpacks.

We want to make sure the pack is hidden from the arsenal, but still available to be spawned, hence the scope entries, to avoid having doubled up backpacks in the arsenal.

The displayName is optional, you can just delete that line, but it's there if you want to give your pack a custom name in the inventory screen for whatever reason.

Next is the important part: we open up a new class, TransportMagazines, which technically has more subclasses inside it, but we can just use the macros to make it simple. You just have to put the classname in the "a" slot, and the number of them you want in the "b" slot. When it comes to backpacks, you actually can over-load them if you want to, just be sure you don't make them so heavy that the soldier carrying it can't run. Unless you want that for some reason.

You can also define more classes, TransportWeapons, TransportItems, and TransportBackpacks, to define weapons, items, and backpacks stored in the backpack, just make sure you use the matching macro for each one or else it won't work and will throw an error.

It's worth noting that this applies exactly the same to vehicles if you want to give them a custom inventory load; they use the same class names and macros used here.

Once you're done, simply enter your backpack's classname in the backpack entry of your soldier, and he should be wearing it when you re-pack and load up your mod.

First, go back to config.cpp and open a new class, CfgWeapons. This is where everything weapon-related will go, so I also recommend making another .hpp file (or multiple) if it starts getting too long. I usually split them into 1 .hpp file per base weapon, in folders categorized by type. If you're gonna use multiple .hpps, put the #includes inside the CfgWeapons class, inside config.cpp, like so:


Next, define the base of the weapon you want to customize. In this case, we'll make a suppressed, bipoded, scoped MXM with a flashlight attached, just so I can show you all of the weapon slots:


This would go into the .hpp file I defined above; if you're not using .hpps for this then put the whole thing into the CfgWeapons class in config.cpp. Then, just put your customized weapon's classname into the weapons[] array of your soldier, and he should spawn with the weapon and all the attachments you defined. Note that if an attachment isn't compatible, it will fail silently (no error messages).

displayName is once again optional, you can just leave it out if you don't care about renaming your customized gun. If you do give it a custom name, keep it short, because it has to fit in the ammo counter HUD element in-game.

The slot names here are the default ones used by all guns in Arma 3, and by most mods too, but in the event they stop working (this will happen with some CUP weapons, for example), you'll have to go to the weapon's config page (be sure it's the CfgWeapons entry and NOT the CfgVehicles one) and look at the WeaponSlotsInfo class. The sub-classes in that class are the slot names for that gun.

The LinkedItems class's subclasses (optic, pointer, etc) can actually be named anything you want but I like to keep them more-or-less the same as the default slot names, minus the optic (no idea why it's called that).

Worth noting that I usually put my weapons definitions into a seperate "core" .pbo, since multiple factions may use the same weapons. If you decide to do this too, don't forget to define the CfgPatches class in the core.pbo's config.cpp, and set it as a required mod for the .pbo containing your factions and soldiers. Other things I put into the core.pbo include (but aren't limited to) custom editor subcategories, custom functions, and some backpacks like RPG carriers that multiple factions might use. You can put the core.pbo and all your faction .pbos into the same addons folder and upload them as a single mod, it's just to help keep things organized, plus it gives a little bit of modularity to the end-user for customized installs.

Finally, I'll go over groups. We'll just make a simple two-man group with the AT guy and the Rifleman we made earlier.

First off, new class in config.cpp (or in a .hpp file, recommended). The group format is pretty simple, the hardest part is positioning them, so I just put them in a basic line and let the AI sort out their own formations.


The name of the first subclass (West in this case) defines what side they'll show up in on the 3DEN browser. Possible values are West, East, and Indep. There's probably one for civilians too but I never looked it up because I never made civ groups.

Next class down is your faction, in pretty much all cases you'll set the name to be the same as your CfgFactionClasses entry. I also usually set the classname here to be the same as my CfgFactionClasses classname, to make scripting easier; I haven't noticed any downside to doing this so far, I'm pretty sure the base game does it too.

Next is the category, you can make this anything you want. This is usually where you'll be dividing into things like Infantry, Mechanized Infantry, Motorized Infantry, Armoured, Air, etc. Don't forget to set the name. You don't have to use tags for these classnames.

Next is the class of the group itself. Set the faction entry to match your CfgFactionClasses class. Copy the icon from what I wrote here. You can change the last part of the filepath to match any of the classnames of the map markers in 3den under the "NATO - BLUFOR", "NATO - OPFOR", or "NATO - Independent" subheadings, if you want different icons for your group (e.g. "b_mech_inf" or "o_armor"). The name is just what you'll see on the list, and the side should be set as I described in Step 3. I don't actually know what the side entry is used for, since nothing bad seems to happen when I forget to change it, but it's probably best to set it correctly just in case.

The next two classes define the soldiers in the group, you can have as many of these as you want up to the group size limit in Arma 3, but you probably won't need to worry about that limit. Don't forget to change the classnames. They have to be unique within this group, but each group can use the same classnames as the others (unit0, unit1, unit2, etc).

The position[] array is relative to the mouse cursor when placing the group, so {0,0,0} means right where you click, and the anything else is relative to that (from the direction the soldiers face, the first number is side to side, second is forward and back, third is up and down). I usually just step them back -2 at a time. I think default wedge formation is ~2.5 back and to the side, going left-right-left-right from the squad leader, but don't quote me on that.

rank defines the in-game rank, which affects skill level (a private is 0.4, then it increases by 0.05 per rank) and seniority if the squad leader gets killed. The first unit listed in the config is always the default squad leader regardless of rank, and then if he dies, it goes from highest rank to lowest. Values are: "PRIVATE", "CORPORAL", "SERGEANT", "LIEUTENANT", "CAPTAIN", "MAJOR", "COLONEL".

vehicle is the classname of the soldier you want to spawn in that slot. You can also put actual vehicles here if you want a motorized or armoured group or something. Just make sure to adjust positions accordingly, especially with multiple vehicles, because if two vehicles spawn inside each other, they'll explode immediately. I usually go for 15 seperation between two vehicles, but you might need more for aircraft or truly huge modded vehicles, like the OPTRE Elephant.

side is the same as the parent class, just match them, but I still don't know what it does.

This is also a good place to use some .hpp files if you're making a lot of groups, which I will leave as an exercise to the reader. One hint I'll give is that I usually use multiple sub folders of .hpps to seperate out infantry, motorized, mechanised, etc. within the main "groups" folder.

If you want to do vehicles too, then I just inherit them like you do with the soldiers, but use the actual vehicle as a base, not the hidden base class. All you have to change is the faction to your custom one, the crew to whatever soldier you want to operate it, and the TransportXXX classes if you want to put custom equipment in them (see the section on backpacks for details, it's the exact same concept down to the classnames). Some vehicles might have different gunners defined for some of the turrets (e.g. a Crew Commander for the commader seat or the door gunners on the NATO Ghost Hawk), in which case replacing them with yours becomes a massive hassle involving subclass inheritence[community.bistudio.com] that I won't get into here (I may add it later as an extra at the end of the guide).

Now just pack the TAG_sampleFaction folder into a .pbo and add the "@TAG_Sample_Mod" folder as a local mod, and see if it loads, and your new soldiers are there. If it all works, you can get started adding your own custom faction and soldiers. Once you're ready to publish it, make sure you don't include the unpacked folder in the upload, it's just wasted bytes.



And that's my guide! If you follow it word for word, you should end up with a small faction of two people and a single group. If it doesn't work, let me know where the problems started so I can track down what I did wrong. And if any of it was confusing, let me know that too so I can try to re-word it or explain more. I stayed up until 8am making this so there's probably gonna be some errors. But hopefully it'll at least give you enough info to figure out how it all works and get a basic working faction going regardless.

Good luck modding!

Someone wanted to know how to do gear randomization, so I'll go over BI's headgear randomization system[community.bistudio.com]. It was created for the FIA to randomize their shemags and bandannas but you can use it on any soldier, e.g. randomizing the Combat Helmets on NATO units. My mod randomizes uniforms and vests too, but I did that by writing a custom function which is out-of-scope for this guide. If you want to use my function, feel free to contact me and I'll show you how to use it, but I will require that you set my mod as a dependency rather than ripping my function.

First, we have to edit our soldier's inheritence so that he can inherit the EventHandlers class. This means going back one parent in "inherits.hpp" so we can open up the base class we were using before. This is necessary because many mods and DLCs add event handlers to all soldiers to make their systems work (for example, SPE44's custom reloads and MG poses), and we want to inherit those event handlers into our new soldiers so they won't break when using those mods and DLCs.


These are the inherits for each of the 3 sides, BLUFOR, OPFOR, and INDEP, respectively. You'll only need the ones whose sides you want to use, as in Step 4.

Next we add the EventHandler class to our soldier. I'll use the rifleman that we made earlier here. Remember, any other soldiers who use your custom soldier as a base class (in this guide, the Anti Tank guy) do not need the new EventHandler class, because the one you define in your base class will carry over into the child classes. This is the big benefit of making a base class to inherit to your other soldiers.


The basic idea here is that we're telling the game that on the initialization event (i.e. when the unit is created), it will check if the unit is local (i.e. the unit is local to the PC the script is running on), and if it is, it will run a function called "BIS_fnc_unitHeadgear", which is what randomizes the headgear. You can just straight-up copy and paste this entire class, I've never had the need to edit anything here, back before I started using my own function.

One thing to note is that the wiki example puts the init directly into the EventHandlers class, but this can cause clashes with other mods or DLCs that are trying to add init event handlers, so I find it's best practice to create your own child class in the EventHandlers class and put all your event handlers in there.

Next up we can define the list of headgear the unit can get. If you don't care about customizing the glasses, then it's extremely simple. All you have to do is add a new entry to the soldier, you can put it just above or below the EventHandlers class, and fill it with classnames and numbers in a weighted list.


This is a weighted list of helmets, meaning each number defines the chance of the element before it to be chosen. The numbers are relative to each other, you can use whatever numbers you want. If you want a chance for no helmet, then you just use "None", as in the example. The helmets in-game usually have pre-defined facewear arrays attached to them that is also randomized, but if you want even more control over the randomization, you can change this too:


This goes in the same class as any custom weapons you've made, CfgWeapons, so you can put it above or below them. I recommend making use of .hpp files for this, especially if you're making a lot of custom hats.

First, we define the helmet we want and create a new class inheriting it, and set the scope entries to 1 and 0 to stop it from showing up in the arsenal, which would cause doubles. Next, comes the allowedFacewear[] array, where we define a weighted list of the glasses just like the headgearList[] array from above. Then you just replace the entries in the headgearList[] array with your new classnames and it should work.

You can also create a list of facewear for no helmet at all (TAG_NoHelmet in this example), all you have to do is define a new class (this one doesn't inherit from anything) that contains only an allowedFacewear[] array, then put that class in your soldier's headgearList[] array. Don't add anything else to this class or else you'll get annoying error messages.

I've decided to release my own function for randomizing uniforms and vests (and headgear and facewear too), the very same I used for Factions Expanded, but with the TTU_FE tag changed to just TTU and with commented code in case people want to see the thought process behind it. Download link is here[drive.google.com].

As of 14/10/2025, I have also added backpack randomization. BE AWARE that if you downloaded and used it previously, you may need to update your arguments if you download the new version, if you were using the boolean.

Instructions are included in the file, as well as some other information. Make sure you credit me in the description of your mod if you upload it with this function included. And don't modify the file. Using it as a reference to create your own function is fine, just don't copy/paste the whole thing with no changes.

The file itself has instructions on use, but I'll quickly go over them here too.

First, you wanna call the function in the EventHandlers class just like in the previous section. You need to call it on init, and you can also call it on respawn if you want the unit to randomize then too.

Second, add in some arrays to your soldier: TTU_Hats[], TTU_Glasses[], TTU_Uniforms[], and TTU_Vests[]. The array names are self-explanatory I hope. These must be weighted lists, so make sure you put a number after each entry to define the chance it'll get selected (you can just enter them all as 1 if you don't care about weighting).

Don't forget to register the function[community.bistudio.com] too, or else there'll be nothing to call.

That should be enough to get it working. More details included in the file, including an example config, make sure you read it!

So let's say you've been working on your faction, using Tanoa Paramilitary uniforms to make a BLUFOR faction. But disaster has struck; your soldiers are spawning with no uniforms!

Arma locks uniforms to sides, so that only BLUFOR can wear BLUFOR uniforms, only OPFOR can wear OPFOR uniforms, and only INDEP can wear INDEP uniforms. Luckily, this isn't too difficult to change.

First, the way uniforms work in Arma is a little weird. The config of the uniform is split between two configs, one in CfgWeapons (which defines things like the weight, how much it can carry, and the textures and model of the folded uniform on the ground) and one in CfgVehicles (which defines the textures and model of the worn uniform, and, importantly for us, which sides can wear it).

The two configs are linked by an entry (present in both configs) called uniformClass: for the CfgVehicles entry, it points to the uniform defined in CfgWeapons, and for the CfgWeapons uniform, it points to the soldier who has the textures and model. Indeed, the CfgVehicles entry is a soldier; the vanilla MTP uniforms use B_Soldier_F (NATO Rifleman) to define its textures and model. I believe this is a holdover from Arma 2, where uniforms were baked into the soldier models and not removable.

So, the way to change the sides is quite simple. For our example we'll use U_I_C_Soldier_Para_1_F, one of the paramilitary uniforms. First you need to find out which soldier you're looking for. Search up the uniform in CfgWeapons, and open up the class. There should be a subclass called ItemInfo. This class contains some helpful entries; containerClass can be used to change how much stuff the uniform can carry, mass can be used to change how much it weighs you down, and uniformClass is the one we're looking for now. Take the entry, in this case I_C_Soldier_Para_1_F, and search this guy up in CfgVehicles to find his parent class, I_C_Soldier_base_F.

Once we have this guy, we need to edit him in our mod. Since we're editing an existing soldier, we'll have to declare his parent class first, just like the EventHandler class editing in the previous section. The entry we need to edit is an array, modelSides[], which defines which sides can wear the uniform linked to this soldier. In this case we'll end up with this:
The numbers are the same I mentioned in the earlier sections of the guide:
0 = opfor/east
1 = blufor/west
2 = greenfor/independent
3 = civilian
Generally, every uniform has a 3 in this array, which is why civilians can wear any uniform.

Something to consider is that we could change the modelSides of all the paramilitary uniforms at once. Each of the soldiers share the same parent class, so if we go up one more parent, and edit the original parent class instead, the changes will propagate down and change all the paramilitary uniforms, like so:

Now you should be able to pack up your mod again, load it up, and admire your new faction with their functional uniforms!