Modifications for TFH (Their Finest Hour)

Note the directory changes:

Version H4 ("Starfire_H4" - January 25, 2014) - work in progress from H3B

Version H3B ("Starfire_H3B" - January 25, 2014) - "GSCG"

Version H3 ("Starfire_H3" - January 22, 2014)

Version H1 ("Starfire_H1" - November 11, 2013) - "TXDI"

Modifications for For The Motherland

Reminder: implement my mod to Agriculture for reduced manpower growth.

Version D5 - This will be for FtM v3.05 + CW + AI mods (this is a "fresh" mod, it does not contain any changes from previous mod versions)

Version C4 (September 5, 2011 for For The Motherland v3.04) "ZMCO" - this is essentially the Starfire B3 mod and "Common Weapons" integrated together and tweaked to be compatible with FtM v3.04 - download here

Modifications for Semper Fi


Version B3 (November 11, 2010 for SemperFi 2.03c beta) "BUFW"

Version B2 (August 18, 2010) "GLWN"

Version B1 (August 17, 2010) "JIWN"

Maginot Line
Hirson 2368 4
Louguyon 2551 7
Metz 2618 10
Cattenom 2552 10
Sarreguemines 2684 10
Wissembourg 2750 9
Strasbourg 2815 8
Selestat 2881 7
Colmar 2947 7
Mulhouse 3083 7
Belfort 3150 7

Modifications of Hearts of Iron III (version 1.4)

Version A4 (Things to consider)

Version A3 (April 16, 2010) "IJVV"

Version A2 (April 12th) "ZXZS"

Version A1 (April 11, 2010) "VDCH"

Essential Fixes for v1.4

The "Spy Fix":

In /common in static_modifiers.txt

# Espionage Modifiers

spy_lower_national_unity = {
national_unity = -0.02

spy_raise_national_unity = {
national_unity = 0.2

disrupt_production = {
unit_repair = -0.02

disrupt_research = {
research_efficiency = -0.01

changing research_efficiency = -0.01 to 0.01 will fix it

commons/defines.lua - contains many of the basic modifiers

How mod-dir works

Setting up the mod-dir

In the main HoI3 folder, there is a folder called mod. In this directory, create a file called e.g. MyMod.mod and a directory called MyMod. The file MyMod.mod is a text file, that can look like this:

name = "MOD_TEST_NAME"
extend = "common"
replace = "events"
extend = "history"
extend = "localisation"
extend = "map"
extend = "interface"
extend = "gfx"
extend = "sound"

Valid "commands" in this file are:

* name = "string"
* extend or replace = "common", "events", "gfx", "history", "interface", "localisation", "map" and "sound".

Extend is usually what you would want to use and works like this: If you write extend = common, any file you put in the common folder of the moddir will override the file in the default common folder. This works for all folders except gfx.

For the gfx folder, only the gfx/anims and gfx/flags is treated this way. To use other modified files in this folder, change a .gfx file in your interface directory and have it point to your new graphics file.

Replace only searches in the new location and if a file can't be found that is needed, the game will not start.

The name variable is shown in the frontend, and you can use a tag (like above) and add your own localisation for it, or just type the name right in.
Starting a mod

To start a mod you either use the launcher, whe you will get a dropdown list with all mods, or add -mod MyMod to the command-line of EU3. Note that the first startup of a mod might take a long time, if you have modified the map.
Modding tips

* It is a good idea for mod makers to put thier version number in the mod name of the .mod file. when this is done, it will show the name and version of the mod in the main page of the game. A date is also usefull. example: "mymod version 1.1.01 3/1/07"
* Only the folders that the mod maker changes for his mod are needed to be listed in the .mod file. there is no reason to list folders that have no content that was changed.

Warning: this only works for two levels deep of directories thus:

How Modding a Tech Works

The first step is to define the tech in the right techfile. The general code layout of a tech looks like this:

rubber_duck_development = {

battleship = {
default_morale = 0.05}

allow = { # Requirements!
battleship_technology = 1

research_bonus_from = {
naval_engineering = 0.5
chemical_engineering = 0.5

change = no # What is this???
on_completion = naval_engineering
difficulty = 1
start_year = 1918
first_offset = 1934 #2nd model is from 1936
additional_offset = 2 #one new every 2 year
folder = capitalship_folder
can_upgrade = yes


As you can see, I have already modded the tech to what I want it to do. Rubber ducks were a very important (if often overlooked) technology. So what does this code do in particular?


rubber_duck_development = {

This is the name of the tech. It will be important later, so make sure you write down the name if it is a bit complicated or overly long.


battleship = {
default_morale = 0.05}

This is the techs effect, in this case it increases morale on battleships. This tech is automatically added to the tooltip of that unit, or as the case may be, the ship building interface. A full list of tech effects does not exist, but I think it is save to say that any value in the unit file is fair game.


allow = {
battleship_technology = 1

These are the prequisites for the tech. Clarification: these are what are required to research this technology, not what researching this technology allows.

It is imperative that the techs are always in the right order!

Tech A = {
Tech B = {
allow = {Tech A}

If they are not in this order, the prequisites won't register (and from my own experience, this can drive you mad!)


research_bonus_from = {
naval_engineering = 0.5
chemical_engineering = 0.5


These are the research boni. Rubber ducks are a difficult feat of naval engineering, so they benefit from that with 50%. Note that in this case, 1.0 = 100%, so don't go and write something like naval_engineering = 50, as that would impact the research with 5000%! Paradox coding convention is that the research boni add up to 100%. I see no reason to break with it, even if there are, apparently, no ill effects if they don't. A full list of what research boni can be applied (up to 4 for each tech) can be found in common/technologies.


on_completion = naval_engineering
difficulty = 1
start_year = 1918
first_offset = 1934 #2nd model is from 1936
additional_offset = 2 #one new every 2 year
folder = capitalship_folder
can_upgrade = yes

This is what I call the end block of a tech, because it is the the big block of code at the end of every tech (boy am I creative!).

on_completion defines which theory or practical value is increased by 1 when the research is done. As far as I can tell, you can only define one value to increase.

difficulty is the difficulty to research this tech.

start_year is the year of the first model that can be researched. If the tech is not listed in history\countries\your_country.txt and the start year is prior to the start of the scenario then the country is assumed to know that tech.

first_offset defines the year of the second model.

additional_offset defines the years of any additional techs. In this case, a new tech becomes available every two years, so the next are 1936, 1938 etc. I have no idea what happens when you leave out either first_offset or additional_offset.

folder is important, because it defines in which tech tab this tech will show up. Remember what I said about the right order of techs? It is actually a very sneaky move by paradox, because quite a few techs that show up on a tech tab are not actually defined in the corresponding technologies file, but elsewhere and then exiled to that tab using the folder line.

can_upgrade seems to be a ship specific line, but I have not tried what happens when you add it to a tech that affects land or air units. It stands to reason that it would work the same, but one never knows. Anyway, it defines whether or not this component can upgrade (so that, for example, a battleship may or may not upgrade its capital armament).

Now that the tech definition is done, to the next part - getting the tech to show up ingame! This is done in the interface/country_technology.gui file.
A standard tech position looks like this:


positionType = {
name = "rubber_duck_development_position"
position = { x = 330 y =160 }

Here, the tech name and the folder come to play. The tech name defines what the position name is, namely the tech name with _position tacked in at the end. The folder defines in which techtab the tech shows up. For easier identification, it is encouraged to place the positions in the right order, or you spend hours searching for a tech position that is simply in the wrong area!

The minimum x appears to be 300, the minimum y appears to be 60, but don't quote me on that. The buttons themselves are about 200 wide (x) and about 35 high (y), so space them out accordingly.

Now the tech is ingame and can be researched, but it still lacks a proper name (the button displays the tech name) and description.
These are done in localisation/technology.csv

You will find there the localisations in 4 languages, in order english, french, german, spanish(?). They are separated by ; with another bunch of them at the end. I suggest you copy an existing line and edit it.


rubber_duck_development;Rubber Duck Development;Rubber Duck Development;Gummi-Enten Entwicklung;;Rubber Duck Development;;;;;;;;;x

I also suggest you edit in the english name for any language you don't speak, or else people will be confused as to why small arms technology suddenly affects battleships.

The tech description is done much the same way, but instead of just the tech_name it is now tech_name_desc; followed by the description in the 4 languages.

Flavor tech level names can be added in the same file, and again with all 4 languages, looking like this:

ENG_rubber_duck_development_1;Rubber Duck Mk. I;Rubber Duck Mk. I;Rubber Duck Mk. I;Rubber Duck Mk. I;;;;;;;;;x

The number at the end denoting the techlevel. The file defines several _0 names, but they never appear in game, because level 0 is the default level, and you can obviously not research not knowing something. They should appear on the unit tooltips, but don't.

How to create a new type of unit (originally written by "Le-Boehm")

(HoI3 is not limited and thus new brigade types can be added)

For this 'How to' I choose good old Air cavalry as our new kind of brigade.

1. Step - The unit itself:

Create a new *.txt in your unit folder. The * should become automatic the new string for this unit, so choose something fitting. Here it becomes the Air_Cavalry_Brigade.txt .
As a first try We simply copy the content of armor_brigade into our file.
Obviously most of the content of a unit.txt is tidy and self explaining, what is indeed very nice.


air_cavalry_brigade = { <= Our new unit-string! No errors please

General Definitions
type = land <= What kind of type; air/naval/land
sprite = Tank <= Which family of sprites
active = no <= Activated without need of activation through research
#is_buildable = no <= HQs and Partisan are e.g. unbuildable units

Land Specials
#can_paradrop = yes <= Jump out transport: yes/no

Naval Specials
#capital = yes <= Capital Ship: yes/no
#hull = 3 <= Not sure yet... But the bigger the ship the bigger the value
#transport = yes <= Naval transport: yes/no
#is_sub = yes <= Submarine: yes/no
#carrier_size = 2 <= How many Cags a carrier can carry

Air Specials
#is_cag = no <= Cag: yes/no. Needed for stationing on CV. Other effects?
#is_bomber = no <= CAS, TAC, V1, V2, Naval, Strategic, transporter has it; MR, Interceptor, Rocketinterceptor not

#Size Definitions
max_strength = 30
default_organisation = 30
default_morale = 0.30
officers = 100

#Building Costs
build_cost_ic = 9.00
build_cost_manpower = 2.33
build_time = 190

#Misc Abilities
maximum_speed = 6.00
transport_weight = 20.00
supply_consumption = 1.33
fuel_consumption = 1.50
radio_strength = 1

#Defensive Abilities
defensiveness = 4.67
toughness = 4.00
softness = 0.20
air_defence = 0.80

#Offensive Abilities
suppression = 0.00
soft_attack = 2.33
hard_attack = 2.33
air_attack = 0.33

urban = {
attack = -0.40
defence = -0.10
amphibious = { attack = -0.60 }
river = { attack = -0.20 }
marsh = { attack = -0.10
movement = -0.10
jungle = { attack = -0.40
movement = -0.4
forest = { attack = -0.30
movement = -0.4
woods = { attack = -0.05 }
mountain = { attack = -0.20
movement = -0.1
hills = {attack = -0.10 }

combat_width = 2

completion_size = 1.7
on_completion = armour_practical

priority = 10 <= It seems that this value show where the new unit stands in the list of units. the bigger the Value the higher the position


Some values have a comment, the rest is self explaining.

Now your unit begins to exist!

2. Step - The String:
Go to localisation/units.csv and open it.
Add at the end of "#Unit names" two new lines and fill it with your new string plus your_string_short.
For example:
air_cavalry_brigade;Air Cavalry;Air Cavalry;Air Cavalry;;Air Cavalry;;;;;;;;;x,,;
air_cavalry_brigade_short;AirCav;AirCav;AirCav;;Ai rCav;;;;;;;;;x,,;

Now your unit has a proper name!

3. Step - The Graphics:

We need in:

a counter-graphic for your new unit. E.g.: /gfx/mapitems/counters/

For my test We copied the an renamed it. Remember to copy the respective .dds in each single folder!
You can edit the .dds easily via an NVIDEA Plugin with Photoshop/GIMP/etc.

Remember also: The sprite is given through the .txt ("sprite = XXX").
A deeper analysis of this is in the working.

Now you need in /gfx/models/ a model picture.
E.G.: /gfx/models/air_cavalry_brigade_0.tga
The Zero is for multi_levels.

Next step: open /interface/counters.gfx
Here you have to register your three counter .dds textures:

spriteType = {
name = "GFX_counter_air_cavalry_brigade"
texturefile = "gfx/mapitems/counters/"
noOfFrames = 1
norefcount = yes

spriteType = {
name = "GFX_map_counter_air_cavalry_brigade"
texturefile = "gfx/mapitems/mapcounters/"
noOfFrames = 1
norefcount = yes

spriteType = {
name = "GFX_small_counter_air_cavalry_brigade"
texturefile = "gfx/mapitems/smallcounters/"
noOfFrames = 1
norefcount = yes

Now you can see your unit!

4. Step - The Activation:
If you doesn't choose "active = yes" in your .txt and doesn't want to build this unit only through events you need an activation through research.

Go to /technologies/Secret Weapons.txt
Add behind helecopters = {...

activate_unit = air_cavalry_brigade

Now you can activate your unit through this research.

5. Step - The Techs:
We also want some development through techs, so our AirCav will gain stronger and stronger.
In fact those nice components in your unit screens are also just the visualization of such Tech modifiers, boni and doctrins.
So if you want them you have to link techs with your unit.

This is also relativ simple.
As an example we will link the Cavalry techs with our AirCav.
Open /technologies/Secret Weapons.txt

Search for:


cavalry_smallarms = {

cavalry_brigade = {
soft_attack = 0.5




air_cavalry_brigade = {
soft_attack = 0.5


Now our AirCav will become greater through new carbines for the flying horsemen

6. Step - The Flavor:
We also want some fancy names for our unit!

Example for Germany.
Go to: /common/countries/germany.txt

air_cavalry_brigade = {
"1. Luftkavallerie-Division"

Somewhere in the section of unit_names = { ... }
Now a Division of your AirCavs will get a proper name.

I have no idea how to give the brigades itself flavor names, yet.
A possible Hint is the command "regiment = { type = infantry_brigade name = "Infanterie Regiment 27" historical_model = 2 }" in the history/unit files.

7. Step - The Multi Level:
We also want to see the development of our unit with new pictures and flavor names.
In HOI2 you had the predefined unit levels in the unit files. If you had the tech the unit upgrade to the next level.
In HOI3 you have one basic unit (with the values in its .txt file) and through researching it get better values.
It is possible to define by which researched techs the unit will treated by the game as a new level. E.G.: If you researched for your Tank has level 3 in Gun, Level 2 in Engine and Level 4 in Armor it will become a Level 2 Tank with new name and pictures.

Basically those predefinitions for multilevels could be set in the files in /units/models.
But there are just some files for the great powers and no generic files.
I'm still searching for those. Any idea where?

The basic realization of those multilevels however is quit traditionally.
The model names are stored in /localisation/models.csv and are handled like in HOI2.
The pictures are the .tga files in /gfx/models/ with the following structure:
STRING_MULTILEVEL =>e.g. Air_Cavalry_brigade_0.tga, Air_Cavalry_brigade_1.tga, Air_Cavalry_brigade_2.tga and so on.