Performance
I'm gonna be brutally honest with you from the start: The performance goal of this DLC was to not decay performance. (Un)fortunately, this doesn't mean we can lean back and ignore it. More content and new features all add to the computations we need to run and I wanted all the new stuff to happen at net-zero performance cost. Essentially, the same thing as for Trial of Allegiance, but with much more. So we had to do something to maintain the status quo with performance. So whenever our performance tracking indicated a slowdown for the first time I took a look at what we could optimize and became a bit disheartened. The French Paradox did a very good job at parallelising much of our code for AAT. There were not many easy options for parallelisation left but we managed to identify a few places. Even on our machines with quite a lot of cores, this wasn’t enough so we took a step back and looked at optimizing the sequential parts of the code. I hope this is quite good news for all of us that run on hardware with fewer cores. The hunt for optimization opportunities led to looking at old systems that now had more data and the uncharted lands of legacy code. I’m just gonna give you a few tidbits of old systems that we found interesting assumptions about the data in or simply interesting ways of solving it.Focuses
I imagine some of you have been with us from the start. Do you remember the size of the original focus trees? And for those of you who don't, simply open up the generic tree to get an idea. Over the years, we've had a large influx of focuses in the focus trees. For example, we have ~60 in the generic focus tree compared to the ~180 national focuses in Belgium, not counting the Belgian-Congo part. And the size of the Belgium focus tree doesn't even compare to the new German one (which is somewhere between 350 and 400 focuses).


Dynamic memory and paralelism
When we started looking at the sequential parts of our parallel code we found a quite interesting trend. There's a lot of dynamic memory allocation. Now every time we do something that requires dynamic memory allocation, the operative system may grab a global lock. Essentially, risking the algorithm to become at least partially sequential. Finding this caused a period of going through the code and eliminating the worst of these dynamic memory allocations.Hidden AAT Inefficiencies
AAT was the expansion that optimized HoI4 (in modern times). Now there’s a drawback with the drastically improved performance: All the inefficiencies from the new systems in AAT were hidden by the drastic improvements in the rest of the game. A lot of old content was optimized by a large margin, and as a result new performance overhead simply got lost in the steadily improving numbers. For example, on my machine disabling the international market automation saved me 2ms per daily update. It’s not a lot (about 0.5% of the overall performance on my machine). But for market automation? Good news, it’s way less now. Bad news, you can still improve performance a very small amount by disabling it (though, manually clicking will have way worse performance in terms of speed). Another hidden inefficiency that we’ve found is the increase in the number of equipment variants. Before, there was a very limited amount of equipment variants in a game but now, there’s a lot of them. Every single MIO update can create a multitude of different variants. And not to mention that International Market and Lend Lease pass these variants around in the game. Now throughout the code base, there are a lot of things that interact with equipment. Every interaction wasn’t adding much but all put together, that’s quite a bit. I won’t say that variants are free but please go ahead and add more, there should be less performance impact now than before at least.Modding
Now let’s leave the area of performance and continue with some other things we’ve looked at from the tech side: New fancy modding stuff. During the development, I got a bit fed up with requests for support for new tooltips. So we sat down and thought: How can we get content developers to write the tooltips themselves? While we couldn't backport Jomini to HoI4, we took some inspiration and made it possible to write more complex tooltips in the GUI and script files.Localization, localization and localization
If you have looked into our localization files before, you've probably noticed something like the following: Traditionally, this meant that `REASON` was replaced with something that was provided by the game (i.e. not scripteD). In many cases, these variables were just replaced with some other localized string. So to avoid having to update the source code every time we wanted to change this, we introduced a new concept to the scripting language: Bound localization. Bound localization simply allows you to bind variables to the localization from script. So instead of opening up the source code, we can now simply update the script files like the following:

Naming is Hard
Imagine that you have a province or state that, depending on who you ask, has a different name. For techs, equipment and a lot of other things we’ve had the support to add country specific names (we call it cosmetic tags) by simply adding the countries tag before the name of it. Now we’ve added the same support to province and state names as well. We can take Turku as an example, this Finish area has both a Finish and a Swedish name (Turku being the name in Finish and Åbo is the name in Swedish). Before we had quite some script to change the name of the state depending on its owner but now we simply have to prefix the name with the correct country tag in the localization file:

Focus Navigation
More national focus means more fun, right? But at some point it just becomes hard to navigate the focus tree. Fear not, we’ve added an option to add navigation shortcuts to focus trees. The new German tree has 6 different navigation icons (as of me writing this).
Focus Inlay Windows
You've probably seen the Inner Circle GUI in another Dev Diary by now, but did you know that the whole GUI is written in script, and it doesn’t contain a single scripted GUI window? The inner circle is the first usage of what we call focus inlay window. A focus inlay window is, similar to the continuous focus window, a GUI object that is drawn inside the focus tree view.. Let’s go through an example: We want to display all the potential members of the Nordic Defence Council and if they have joined. For some reason it’s also very critical for us that we show the leaders of the countries. Something like the following: