[2020] Dev Diary: 1.9 Patchnotes and Modding Updates

: You can find the details for this event on the announcement page [url=https://steamcommunity.com/ogg/394360/announcements/detail/1716372156952143833]here[/url].

Today's Development Diary by Podcat[pdxint.at]



Hi guys! Here is the promised bonus dev diary. First up is the full changelog, and after that we will be going through all the new stuff we have for modders.

1.9 'Husky' Patchlog

See the full patch log here: https://pdxint.at/2P84LIj

Modding

1.9.0 will include a lot of tools/improvements that will hopefully help modders developing their awesome mods. Bug fixes and small improvements are too many to list here and can be found in the patch log but we will be listing more major stuff in this dev diary.

More effects, triggers and game variables and more variable support

We added quite a bit new effects/triggers and game variables with new free patch. Full list can be found in in the patch notes or the documentation files that are generated by game.

In addition to those new scripting tools, we also added more variable support to existing effects/triggers. And now hoi4 scripting language supports storing tokens as a variable. For example you can do the following:



Here we are storing token infantry_equipment in a temporary variable named to and later we are using this stored token in add_equipment_to_stockpile effect.

At the moment following objects can be stored in variables and all effects/triggers should be able to accept such variables

ideology/ideology groups
equipment types
operation

We have plans for adding support for more, feel free to have suggestions for other types of tokens if you thing they would be useful.

We are also adding a better documentation support for our scripting language. Following html files are output of our new script documentation tools:

Effect Documentation[common-assets.paradoxplaza.com]

Trigger Documentation[common-assets.paradoxplaza.com]

Modifier Documentation[common-assets.paradoxplaza.com]

Dynamic Variables Documentation[common-assets.paradoxplaza.com]

History Logger

"History Logger" is a tool that we developed to observe AI gameplay and now it is available for public as well. More details available on AI dev diary[forum.paradoxplaza.com]



You can see some examples using following links:

https://common-assets.paradoxplaza.com/hoi4-devdiary/history_viewer.html?zip=1.zip

https://common-assets.paradoxplaza.com/hoi4-devdiary/history_viewer.html?zip=2.zip


We hope that it will help people that makes overhaul mods or AI mods. To use it you need to run game you need to lunch the game with "-hands_off" option which make game automatically start up on observing country defined NGame::HANDS_OFF_START_TAG (Or you can manually start the game and run console command "history_logger"). During the run, the game will collect data and dump it on every month under "documents/user/Hearts of Iron IV/history_dump" folder. Once you believe the game collected enough data, you can zip the contents of that folder and load it to game\tools\history_viewer\history_viewer.html file.

The hands off will also output the test conditions that you want to satisfy. You add more conditions to game\tests if you want and they will be reported as a success or fail under user\Documents\Paradox Interactive\Hearts of Iron IV\logs\tests



Crash Logging

The game will run the last executed script or last loaded script/history/save line if something goes wrong during script execution or save game loading and the game crashes. Which hopefully will give you more information on why it crashes and avoid the problem until we solve the crash itself.



This information is only stored if the game is launched using "-crash_data_log" option (it does have a performance hit so I would suggest not to enable it during regular development). The crash will be outputted to user\Documents\Paradox Interactive\Hearts of Iron IV\crashes\...\meta.yml which should give you the file & line info

If the game is crashing while loading a save game, I would suggest changing save_as_binary to no under user\Documents\Paradox Interactive\Hearts of Iron IV\settings.txt so you can see the contents of the save in a text format.

And of course please make a bug report if you encounter crashes so we can actually fix them.

Country Tag Aliases
We are adding an aliasing system for country tags. These aliases will work just like a country tag (they are a 3 letter tags that can be used in most places you can use a country tag) but during game play they can be mapped to different countries. For example:



SPD, VIC and MOT are country tag aliases. SPD maps to a country with original tag of SPR (which is a real tag) and has country flag SPR_carlist_spain_flag. When a script calls



It will find the correct SPR and add the political power to that country.

In addition to original tag/trigger combination you can also map a country tag alias to a variable, event target or a scoring system. In previous example MOT is a country tag alias that maps to variable generic_operation_target which is set differently for each country in another part of the script.

Country Scorers

We added a scoring system to our scripting language. Examples can be found under game\common\scorers\country

Here you can score countries using a bunch of triggers and modifiers and then use that scoring entry to in effects such get_sorted_scored_countries and get_highest_scored_country.

This system is also used by various AI implementation. For example operation AI is fully scripted and uses this scoring system for picking targets. Decryption AI also uses this scoring system for finding a decryption target.

Modifier Definition
It is now possible to add custom modifiers using scripting language. These new modifiers are stored under game\common\modifier_definitions

Once such modifier is defined, it can be used in things that awards a country/state/leader modifiers. It will show up in the modifier tooltips and you can access the value of that modifier in effects or triggers using "modifier@modifier_token" under country/state scopes leader_modifier/unit_modifier under unit leader scopes

Control + Alt + Click to open script files


You can use control + alt + click in debug mode to open script files for things like focuses, ideas, decisions, events, researches and spirits



Here is an example of editing an existing focus. As you can see we also improved reloading so focus tree is no longer scrolled to default position when you change a focus!

More AI strategies

We added a lot of new strategies to override/alter the behavior of AI. It will be possible to create AI strategies to make AI request more units for specific fronts or make AI force activate/not-activate its plans, change aggressiveness etc. These strategies helped us quite a lot for making Allies invading Axis more successfully in Europe.

Moddable Game Speed

This was asked for by a bunch of modders working on MP mods. It is now possible to mod game speed by changing values of NGame::GAME_SPEED_SECONDS

Modding Operations

The Operations system was designed to be very scriptable and can be modded extensively to make new operations.

At the basic level, an Operation is made up of three Operation Phases. In the Vanilla implementation, these phases are pulled randomly from three separate pools: one each for infiltration, execution, and exfiltration. You are by no means restricted to doing that, though (and there are exceptions - for example, fake intel operations don’t require infiltration or exfiltration).



Each phase has its own set of requirements that decides whether that phase is even available (so for example you can’t get the submarine infiltration method if the target country is landlocked). Every phase can also have equipment requirements, which will be drawn automatically from the stockpile. For expensive equipment like transport planes, you can set the equipment to be returned at the end of an operation.



For some phases, we use industry cost, which is rendered as a number of factories for a number of days.

The probability of a phase being selected is determined by a base value that can be modified much like ai_chances in events etc.

Each phase has three localisations associated with it: A plan, an outcome, and an extra outcome if the operation fails. It further has two images it needs: one picture for the overview at the top and another, smaller one for the phase icon on the map.

With the Phases done, let’s get into how operations actually look like in script:





It looks a lot more scary than it really is. Going from the top:



This is mostly Gui stuff and shouldn’t be a big mystery for modders. The Icon is the picture shown in the Agency view. Map_icon is the icon that is shown on the map when an operation is available. Name and desc are the name and description localization strings. Priority determines where in the list of available operations this operation is displayed.



Days is the duration of the operation once it starts. The preparation phase is determined entirely by gathering the required resources.

Network strength is the strength of the network in the target country.

Operatives is the number of operatives necessary to start the operation. This also means the operation is not available until the country has at least that many operatives. This can make testing more advanced operations that require 3 or more operatives a bit tricky.

The visible = {} trigger works much like you are familiar with from decisions and ideas. If it evaluates true, the operation is visible.

Not shown are allowed = {} and available = {} triggers. Allowed = {} is checked to see if an operation should ever be available for a country. This is particularly useful if you want to have an operation that is only for certain countries (like the Heavy Water Raid only being available for countries other than Germany). Available = {} checks if the operation can be taken (if it is visible). This is useful if you want the player to know that an operation might be possible before it actually is (by making the visible = {} trigger less strict than the available = {} trigger).



Selection_target limits the amount of available targets that the operation can be conducted against (FROM is always the target country, FROM.FROM is the target state if there is one, ROOT is the country that starts the operation). This is mostly useful to keep the game from checking against every possible tag or for every state on the map, which hurts performance.

Selection_target_state is a trigger that defines what kind of state can be selected for an operation (in this example, the state has to have some resistance). In combination with selection_target, this means that in this example you can only select states in the target country that have resistance.



Equipment is a separate category that determines what equipment is needed for an operation. As said above, equipment can also be tied to operation phases, but using this parameter is useful for establishing a baseline cost that is independent of what phase is being selected by the game.

Required_tokens is checking for tokens that the country has. In Vanilla, tokens are only granted from other operations, but they could theoretically also be gained through focuses, events, or decisions. They don’t really serve a purpose in and off themselves, but they are useful for forcing the player to complete an operation before they can execute another, making the two connected.



Risk_chance determines how likely it is that things go wrong for your agents. In the example, it is set to 20%. If the RNG decides that your agents are going to have a very bad day, it runs an on_action called on_operative_detected_during_operation, which decides the relative probability of various outcomes (captured, killed, injured, forced into hiding).

Experience is the experience gained by operatives assigned to the mission.

Outcome_chance is the probability that you gain only the base outcome.This value paradoxically means that the lower it is, the more likely that the player gains an extra reward. If you want an operation that can fail, you can just make the base outcome bad, in which case outcome_chance would be the failure chance.

Outcome_modifiers specifies modifiers that affect the outcome. These modifiers are set elsewhere, like Agency upgrades, national spirits, ideas and ministers etc. Depending on the sum of these modifiers, the base outcome is more or less likely (making the bonus outcome more or less likely in turn since the operation always rolls an outcome).

• Possible modifiers include:
  
• Outcome_modifiers (modify outcome chance)
  
• Risk_modifiers (modify the risk chance)
  
• Cost_modifiers (modify the cost in equipment)

A particularly neat feature is that operations can define entire modifiers by themselves, which makes this system very flexible. In other areas, you need to have a modifier be defined in code, while here, you can just define a modifier by giving it a name in the operation. You can then refer to that modifier by name when you add it to a minister, a technology, or a national spirit.



This is where the magic happens. Outcome_execute is essentially just a field to run an effect (not much different from, say, a decision or a focus in that sense). Outcome_extra_execute is another effect field. Outcome_chance is what decides whether the operation runs outcome_execute or outcome_extra_execute when it finishes (outcome_chance is the chance that it runs outcome_execute instead of outcome_extra_execute).

In this example, a simple random_list takes over if the game rolls a bonus, to determine how big the bonus is. You can do a lot of cool stuff here - an operation that can lower stability in an enemy nation could, for example, have a small chance to start a civil war under some circumstances.

If you want to have the operation always have the same outcome, put the effect it should run into outcome_extra_execute and set outcome_chance to 0.

Outcome_potential is essentially just there to generate a tooltip for the expected outcome of the operation before it is run. As you can see, it is the same as outcome_execute, to show the player the minimum they can expect to gain from running the operation.



This is the part that sets up how the phases are selected. Every phase has a base probability, and as you can see, that probability can be modified.

As a special treat the operation pictured above contains a bug that I only noticed while I was writing this. See if you can find it!