cwtools / cwtools-hoi4-config

.cwt config for Hearts of Iron IV

cwtools-hoi4-config .cwt config files for Hearts of Iron IV

To use these:

1. Clone this repository to a filepath, e.g. D:\Git\cwtools-hoi4-config. (or copy the contents of the zip you can download)
2. Open VS Code, and go to File, Preferences, Settings 2.a. To make the changes only apply to this folder (not all folders on your computer), change the tab at the top to "workspace settings"
3. Set "cwtools.rules_version" to "manual"
4. Set "cwtools.rules_folder" to the path above. e.g. D:\Git\cwtools-hoi4-config
5. Re-open VS Code.

Once you make changes to the rules, you can press "Ctrl-shift-p" and select "Reload window" to easily restart the extension.

See https://github.com/tboby/cwtools/wiki/.cwt-config-file-guidance for guidance on the file format

Contributing If you'd like to contribute, press the pen icon on any file, then press "Create a new branch for this commit and start a pull request". You can then make further changes as a "pull request". When done, mention it in the pull request and your changes will be included.

cwtools-hoi4-config's Issues

Scan for unused things big list

For optimisation and maintenance purposes, removing unused content is clearly a good idea. There are a whole load of things that could be scanned for, so I've broken this list up into three sections.

The first are things that don't require any sort of conditionality and can be used anywhere. Scanning for them is as simple as seeing if they are, anywhere, mentioned. The second group doesn't require any sort of conditionality but we'll need exclude certain places when seeing if they are used. Finally the third group require some of conditionality, so so will be harder to handle.

No conditionality and can scan everywhere:

• GFX flags that aren't used
• portraits that aren't used
• OOBs that are never called
• GFX assets that are never defined, for those that need to be defined to use

No conditionality but need to only scan certain places:

• localisation strings
• GFX assets that are defined but then never called in code
• country and global flags that aren't ever checked
• opinion modifiers that aren't used
• ideas that aren't used

Requires conditionality:

• ai_chance on events with only one option
• is_trigged_only = yes events that aren't triggered anywhere

Allow for "dynamic" modifiers in modifiers.cwt

I recently made a pull request for some vanilla modifiers but these modifiers also extend to custom buildings, ideologies and etc found in mods and should be "dynamic".

production_speed_air_base_factor = country
production_speed_anti_air_building_factor = country
production_speed_arms_factory_factor = country

communism_acceptance = country
communism_drift = country
democratic_acceptance = country
democratic_drift = country

If i created a building called test_building production_speed_test_building_factor would be valid but show as a F+ in CWTools.

If I created an ideology called nationalism nationalism nationalism_acceptance would be f+ in CWTools.

Can these be made dynamic? e.g [ideology]_acceptance = country

Suggest array usage

We use every_state with a limit of cores quite a bit. For example:

            every_state = {
                limit = { is_core_of = SOV }
                remove_core_of = SOV
            }

This can be done with a lower performance cost by:

            for_each_scope_loop = {
                array = SOV.core_states
                remove_core_of = SOV
            }

Throwing an info when an existing array can be used would be great to push people towards using them. If there are other arrays like this that can also be used, suggesting them as well would be great.

Dynamic Modifiers Unsupported

Dynamic modifiers give a false positive:

'meta_effect' Unsupported

meta_effect supports more or less anything inside.

Likely will need a new data type in which just anything goes - @Yard1

Example in code:

HOI4 - Tag aliases not recognised

A recent new function of HOI4 are tag aliases - they work like normal tags (three-letter codes), and all commands/triggers that accept tags also accept aliases.
However, they are dynamic handles, which can be set dynamically based on event targets, variables, triggers or weighted random scoring.

In the image above, UPC is whatever tag is the UPC_leader global event target, and the same goes for NPA and npa_leader. ZHL and SZF are tag references that apply for the base SZC tag in specific conditions.

start_experience_factor in air_wings

Not expecting start_experience_factor in air_wings = { STATE_ID = { xxx }} blocks, at the xxx positions.
NOTE: multiple are possible, and need a defined air wing above them.
Example:

Ingame result is:

check_variable short syntax

check_variable has as short syntax form:

check_variable = { var_name = var_name_2 }
check_variable = { var_name < var_name_2 }
check_variable = { var_name > var_name_2 }

https://hoi4.paradoxwikis.com/Variables#check_variable

Apart from long syntax, only = is implemented in the library at the moment, < and > are missing.

https://github.com/tboby/cwtools-hoi4-config/blob/f553300af895ef8a9f80f924218e0b6dc72eba2d/Config/triggers.cwt#L93-L109

Scan for unused gfx

cwtools/cwtools-vscode#28

Removing Branch CV_development

I will remove this branch unless anyone wishes to keep it.

It is out of date, and unneeded

Tag.GetCapital is not recognized in localization

[TAG.GetCapital] outputs the current capital of the tag but currently throws and error

Localisation key commands don't work - CW226

They break pretty often:

@tboby knows what the issue is

`template_roles` does not contain all the roles

In /common/ai_strategy folder this strategy returns an error since paratroopers are not recognized as a land unit subtype. If it is corrected to paratropper without an s at the end it works. The issue is that this code is in the base game and I assume it should be correct.

ai_strategy = {
	type = role_ratio
	id = paratroopers
	value = 0
}

Dynamic Flags False Positive

Flags can be dynamically created using the following syntax:
<flag name>@<scope>

For example:
SZC_alliance_@FROM

Sadly, there isn't really anyway to support this fully (at least, not that I can think of), but bumping flag errors down to "info" level if there is a flag saved that is a prefix of it would be great

Scripted GUIs Aren't Scanned

So if a flag is set in one, it will give errors like this:

Since it doesn't see that it has been set

Scan for missing portraits

Scanning for portrait calls that are invalid would be great. They don't need to be defined anywhere, they are just called in one of two ways

picture = JustFileNameWithoutPathAndGameChoosesTheTAGFolderInLeadersBasedOnCurrentScope

or

portrait_path = FullPath

Scan for potential use of scripted effects and triggers

As you can imagine, most large mods rapidly create a long and useful list of custom scripted effects and triggers. They are immensely useful, letting sweeping changes be made easily, avoiding bugs and just keeping the line count down to make maintenance easier.

However, with such a long list of custom scripted effects and triggers, remembering to use them can be pain. So, scanning for any triggers or effects that match an existing scripted effects and triggers should show an info suggesting you make use of it.

For example, in KR we have the following scripted effect:

remove_all_ministers = {
	hidden_effect = {
		remove_ideas_with_trait = head_of_government
		remove_ideas_with_trait = foreign_minister
		remove_ideas_with_trait = economy_minister
		remove_ideas_with_trait = security_minister
	}
}

If I had this in an event effect:

add_politcal_power = 50
add_ideas = new_guns
hidden_effect = {
	remove_ideas_with_trait = head_of_government
	remove_ideas_with_trait = foreign_minister
	remove_ideas_with_trait = economy_minister
	remove_ideas_with_trait = security_minister
}

An info should be thrown suggesting I use the remove_all_ministers scripted effect. Same can be done for triggers. Would no doubt save us many lines.

Check for proper equipment syntax

cwtools/cwtools-vscode#32

Scan for unnecessary scopes

A minor but annoying thing I have noticed is a lot of unnecessary or duplicate scoping. There are three examples I can name of the top of my head, but they are all broadly the same thing.

trigger = {
	NOT = {
		is_in_faction_with = GER
	}
	NOT = {
		has_government = totalist
	}
}

Is clearly just a longer version of

trigger = {
	NOT = {
		is_in_faction_with = GER
		has_government = totalist
	}
}

Again here

trigger = {
	JAP = {
		is_in_faction_with = GER
	}
	JAP = {
		has_government = totalist
	}
}

Can be shorten to

trigger = {
	JAP = {
		is_in_faction_with = GER
		has_government = totalist
	}
}

Finally, mistakes like this

trigger = {
	JAP = {
		is_in_faction_with = GER
		JAP = {
			has_government = totalist
		}
	}
}

Which can be cut down

trigger = {
	JAP = {
		is_in_faction_with = GER
		has_government = totalist
	}
}

None of these are major errors, but they do make code longer and harder to read, and now can also be a sign of a bug where someone meant to type in a different scope

Case sensitivity checks for file references

Extra important for Linux users. #77 will cover this partially

Always check that tags are written out in all-caps

What it says on the tin

Scan for missing subunits

Having division templates with empty subunits is a consistent and guaranteed cause of CTDs. I'd like to suggest adding a CWTools error for any missing subunits in the horizontal or vertical axes.

Notice the missing (0,1) subunit in the template above

production_speed_[BUILDING NAME]_factor unrecognised

production_speed_[BUILDING NAME]_factor is unrecognised

For example, production_speed_coastal_bunker_factor

Scan for contradictory/duplicate triggers

Seems a simple extra thing to scan for and might catch a few extra bugs here and there.

For example, an error should be thrown for the following trigger:

trigger = {
     has_war = yes
     has_war = no
}

Second, an error should be thrown for the following trigger:

trigger = {
     has_war = yes
     has_war = yes
}

Scan for incorrect new line syntax

To make a new line it is a backwards slash and then a lower case n. That is it. There shouldn't be a space either side, no upper case N and no forward slash. If you want a full line break then it is '\n\n', again, no spaces.

I really hate Syndies.\nLike, so so much. <- Correct
I really hate Syndies. \nLike, so so much. <- Incorrect
I really hate Syndies.\n Like, so so much. <- Incorrect with single space, though multiple spaces can be used for indentation
I really hate Syndies.\NLike, so so much. <- Incorrect
I really hate Syndies./nLike, so so much. <- Incorrect

Seems an easy, ish, thing to scan for

Check for unneeded ai_chance

cwtools/cwtools-vscode#31

Make sure load OOB commands are hidden and have a custom tooltip

Avoids an ugly 'tooltip'. Only needs to be done in places you can see clearly

NOR tag thought as NOT-OR command

Nice and simple bug here. CWTools is reading the NOR tag as the NOR command, which it isn't.

HOI4 sees NOT as NOR, so that NOR can be the tag for Norway.

Example of false error message here:

^ Unsupported in Code

^ has valid used in code, such as this:

check_variable = { global.LEC_voters^num > 1 }

But sadly this leads to:

Stopping parsing of the file there.

Create leader effects picture path

Talking about HOI4 here, there might be something similar in other PDX titles.

There is quite an oddity with the way PDX made picture assignment for leaders.
You can either use gfx files name that is located in current countries leaders folder or use full path to that file.

Let's say the countries tag is BRK. Both of this cases will work fine for create_country_leader:

create_country_leader = {
	picture = "Portrait_BRK_Graven.dds"
}

create_country_leader = {
	picture = "gfx/leaders/BRK/Portrait_BRK_Graven.dds"
}

create_field_marshal, create_corps_commander, create_navy_leader on the other hand won't accept the full path as picture. Unlike create_country_leader , those three use another field to get the full path portrait_path.

# works fine
create_field_marshal = {
	picture = "Portrait_BRK_Graven.dds"
}

# won't find the picture, no errors in the error log
create_field_marshal = {
	picture = "gfx/leaders/BRK/Portrait_BRK_Graven.dds"
}

# works fine
create_field_marshal = {
	portrait_path = "gfx/leaders/BRK/Portrait_BRK_Graven.dds"
}

Right now portrait_path is not recognized by the parser: Unexpected node portrait_path in create_corps_commander. So it should be added to those three effects and those three only, create_country_leader will return an error on game startup if it is used in there.

Ideally there should be either portrait_path or picture in those effects, not both of them at the same time.

Inbuilt Arrays Not Recognised

The following link has a list of game variables - there are several arrays mixed up in the lists.

https://hoi4.paradoxwikis.com/Variables#Game_Variables

Scan for incorrect localisation colouring

This has two parts; checking for use of invalid colour codes, but also checking that it is closed. You need a §! at the end to stop it colouring everything after, so for every §+letter there should be an equal §! on the same string.

Check for events which are never triggered

cwtools/cwtools-vscode#25

Logging issue in decisions

The decission below creates the following error: Localisation key inline uses command GetDateText which does not exist in data type Country.\nor\nLocalisation key inline uses command Root which does not exist in data type Country.

SOV_CHE = {
	sov_CHE = {
		allowed = { tag = SOV }

		available = {
			tag = SOV
			CHE = {
				NOT = {
					controls_state = 672
				}
			}
		}

		activation = {
		}


		Is_good = yes


		fire_only_once = yes


		timeout_effect = {
			log = "[GetDateText]: [Root.GetName]: Decision timeout sov_CHE"
		}

		cost = 50
		complete_effect = {
			log = "[GetDateText]: [Root.GetName]: Decision sov_CHE"
			country_event = russia.1
		}

		ai_will_do = {
			factor = 1
		}
	}
}

I'm not sure what's the best way to go on about this as the following allows localisation which is correct

cwtools-hoi4-config/Config/effects.cwt

Lines 386 to 388 in ab362fe

	### Print message to game.log - Can be localized.
	## scope = any
	alias[effect:log] = localisation

and localisation allows GetDateText & GetName

cwtools-hoi4-config/Config/localisation.cwt

Line 22 in ab362fe

GetDateText = any

What would be the best way to resolve this?

Enforce tag-less global flag usage

Global flags are global, surprise surprise, so use of scopes around them is pointless.

JAP = { has_global_flag = JAP_Fading_Sun }
is the same as
has_global_flag = JAP_Fading_Sun

Thus for neatness, an info should be shown saying that isn't needed. Same for setting global flags.

DLC zip files not being validated

zip files in dlc folder are not being loaded and validated, despite having gfx entries (such as entities).

Targeted variables are not recognized as variable_field

Numbers or variables work fine, target variables with @ character in them don't.

num_units_on_climate@cold_climate
avg_units_acclimation@cold_climate

### Compares a variable to a number or variable
## scope = any
alias[trigger:check_variable] = {
	variable_field = variable_field
}
### Compares a variable to a number or variable
## scope = any
alias[trigger:check_variable] = {
	var = value[variable]
	value = variable_field
	compare = less_than
	compare = less_than_or_equals
	compare = greater_than
	compare = greater_than_or_equals
	compare = equals
	compare = not_equals
}

Scan for duplicate localisation

If a localisation key is defined more than once, you've got a problem. There are two way of doing this, one easy and one hard. The easy one will catch most bugs, the hard one will catch all.

The easy way:
Simple scan inside a mod's localisation folder for identical keys. If you find any, throw an error. Simple, easy and no false positives. Catches most errors but not all, wouldn't catch collisions between vanilla localisation and mod localisation.

The hard way:
Scan both the mod's localisation folder and vanilla's localisation folder. If you find any that match inside the mod folder, throw an error. If you find any that match in vanilla and in the mod, the following things also need to be checked:

• If the mod replace paths vanilla, don't throw an error
• If the mod overwrites the file, don't throw an error
• If the mod localisation key is in localisation/replace, don't throw an error

If none of those are true, then throw an error.

Easy or hard method then? 😅

Check that all three flag sizes exist

The game does not check that flags in gfx\flags exist for all 3 sizes of flag graphic, large, medium, and small. This causes some small graphical problems if not all 3 sizes exist.

Note that a cosmetic tag does not necessarily need a flag, but if one size exists, all 3 sizes should exist.

Scan for temporary variables referenced badly

As is in their name, temporary variables are temporary.

They clear at the end of a script, so referencing them outside of that script will clearly cause a bug.

The rules are strange, wiki has the the full story: https://hoi4.paradoxwikis.com/Variables#Temporary_Variables

unit_leader_event issues

unit_leader_event cannot be defined with current rule features. The starting scope and the ROOT scope are both in country scope, but explicitly calling THIS will change the scope to unit_leader scope.

	option = {
		name = qieflavor.14.b
		trigger = { is_ai = no }
		# in country scope
		add_political_power = 15
		hidden_effect = {
			THIS = {
				# in unit_leader scope - in country/news events, THIS would just be the current scope
				retire = yes
			}
		}
	}

As far as I know, this is the only instance of THIS scope working like that, though I suspect it may work the same way in state_events. Will need to check.

Event Graphing Function Issues

The very useful event graphing function is currently disabled by default, requiring you to add:

## graph_related_types = { }

under the types of the thing you want to graph, events in this case, creating a barrier to people using this very useful function.

In addition:

1. For unknown reasons, some event files fail to graph at all, just giving a blank screen.
2. The save graph as image function appears to do nothing

Don't show coincidental localisation text for triggers/effects

Sometimes script elements have the same name as a localisation key by coincidence.
E.g #11 (comment) (owner is both a trigger/effect and a loc key).

Two possible approaches:

1. Easy: If you hover over an element which matches a trigger/effect rule, suppress localisation based hover text. (Blacklist)
2. Hard: Only show localisation hover text for specific rules, perhaps types, scalar, localisation and modifiers (Whitelist)

Vanishing problems

This is happening in two files of ours:

"_peace_conference_scripted_triggers.txt", // common\scripted_triggers\_peace_conference_scripted_triggers.txt
"00 Laws.txt", // common\ideas\00 Laws.txt

When loading in those files are shown to have a multitude of problems such as these:

But when you actually go into those files, the problems vanish.

Updated Trigger Docs

Updated Trigger docs from 1.6
1_6_trigger_docs.txt

Check that mutually exclusive focuses have nothing between them

What it says on the tin

Variables Behave Unpredictably

Sometimes variables written shorthand seem to not behave well, even if declared in the same scope. The tooltip states as such:

This seems to happen quite randomly as seen in the second example. The error disappears if replacing the offending variable (game or otherwise) with a plain integer as seen:

This is the tooltip on the function itself

The issue persists over seemly all of the variable (temp and true) functions

Scan for proper diplomatic relation syntax

cwtools/cwtools-vscode#30

Focus text field not supported

For most focuses the ID is also a loc field, but you can overwrite this by adding in text = some_loc_key and it will use that instead.

This throws false positives, saying that the ID is missing localisation, which technically true, is missing the point.

Example here;

Combat Tactic False positive

The following code is producing this error: tag used in wrong scope. In Combat but expect Country

tactic_banzai_charge = { #Special Japan attacker tactic
	is_attacker = yes
	trigger = {
		tag = JAP
		is_attacker = yes
		phase = no
	}
	
	active = yes
	
	countered_by = tactic_overwhelming_fire
	
	base = { factor = 4 }
	picture = tactic_banzai_charge
	
	attacker_movement_speed = 0.1
	attacker = 0.25 
	defender = 0.1
}

This is valid HOI4 code and this is a vanilla example.

I'm still learning how to modify the config but from what I see the issue is the scope.

## replace_scope = { this = combat root = combat from = combat }

https://github.com/hiddengearz/cwtools-hoi4-config/blob/master/Config/common/combat_tactics.cwt#L15

How would one go about having multiple scopes?

edit: Would it be ## scope = { combat country } ?