• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Hi everyone, welcome to another dev diary! Last week we talked about changes to frontlines (both UI & backend and AI) and today I want to talk about some of the other fixes and changes we have been up to.

1.7 ‘Hydra’ is a chance for us to rewrite and improve some pesky systems and to step up and go 64-bit, so this diary is going to get a little technical :)

64-bit
1.6.2 will be the last 32-bit build of HOI4 and we will be leaving it (and older as normal) on steam for those who still want to access it (and make sure to mark the build). We also will not be converting any of the old versions to 64-bit. It would simply be too much work. Because of this we have decided to up the big decimal on our version number to 1.7. 1.7 ‘Hydra’ will be fully 64-bit supported on Linux, Mac and Windows and it has been a big undertaking. There are many reasons for this change. Some platforms like Mac are phasing out 32-bit quite aggressively and we don’t want to end up with people not being able to play on there. 64-bit lets us use newer compiler features and a lot more possibilities code wise in the future. It is also about time, because it felt like a lot of the industry did this over 5 years ago :D

As a player you won’t notice a huge difference. We haven’t seen any big performance improvements for example, although I wouldn’t say that it’s impossible some areas might improve as our investigations have been pretty shallow. 64-bit is tricky in that on one hand we get access to the possibility of more optimized code, CPU registers etc, but it also takes up more memory, and memory is often highly impactful on speed too. We see it as an investment into the future where we know we can start taking advantage of things now that the foundation is in and make it easier for us to work.

We have already seen some of this internally where we during this work have been able to replace a lot of basic code structures dating back to the Year of our Lord 2003 :)

Convoy system
The old code system keeping track of your favourite little boats has long plagued development, and after 1.6, when we still had some issues, we decided it was simply best to take it out back and shoot it. 1.7 comes with a new system rewritten from scratch. The old convoy system was operating in a way where everyone could control it, and by association, everyone could also break it at any time. It would also swap convoys in between the country’s supply and the assignments at every single tick, swapping them around all the time, and convoys getting lost because there was no sense of ownership and control over the convoys. It was a nightmare.

The new system is a centralized system where each country has one instance of a class that has full ownership and control of convoys, and any other gameplay code that needs convoys can request them from this system but never have real control over them. This “magically” fixes bugs with convoys disappearing from the game because it’s not possible to write code like that anymore. It’s stability by design along with the other great and exciting stability changes that we are bringing to you with this patch.


Naval Balance Changes
We have been looking at convoy escorting, subs, detection and raiding and making improvements:
  • Subs can now fire also while withdrawing
    • Convoy escort missions were too binary. Either you have protected the convoys in time or not. Arriving on time provided too much of an advantage to the escort and thus made sub raiding less viable. Subs will now get an extra volley or two in most combats, making raiding with high-quality subs against low-quality escorts more viable.
  • We increased submarine detection chance from passive detection (hi bitmode) and lowered detection chance from firing torpedos. Detection chance from passive sweeps now scales parabolically so that large differences in detection and visibility will be much more pronounced.
  • We gave carriers passive sub detection and gave them a detection increase in doctrines. This makes them more viable in their historical roles in the Atlantic.
  • We also increased detection values on some later radars and a bit on sonar, to make detecting subs a bit easier.
We have also been looking at various issues related to convoys and how they defend themselves against naval bombers. There were many different problems:
  • Unit transports died too easily vs naval bombers, this was extra bad for the AI which generally suffered more to this than a player would.
  • In small naval bombers vs transports as above, we also had way too high casualties for the planes
  • Because convoys are not “real” units they would heal up after battle, so unless you sunk them there was no real damage to the enemy.
To deal with this, we have made several changes:
  • Troop transports get a special defensive boost in the particular case of being attacked directly by naval bombers
  • The anti-air formula for ships shooting back has changed so that partial damage is taken into account. We now essentially roll a dice for partial damage allowing it to kill planes. Before, weak ships like convoys that got hit a lot had much to big an impact, and early naval bombers didn't really deliver. This should be a lot nicer now.
  • At the end of battles we add up all the damaged convoys and for a fraction of them we roll a dice based on the damage to see if they sunk from that damage. The kills get attributed to the last to strike them during the regular battle.

When it comes to regular combat we wanted to help out carriers and capital ships a bit and we felt the more realistic way of doing that was to give them a time at the start of the combat when they are the only ones active. Carriers and aircraft are active straight away. Some ticks later capital ships and subs get to fire and last screens. This gives a bit of a boost to those bigger ships and represents their longer ranged weapons better.

Script-Side Performance Improvements
1.6 came with a number of new script features to improve performance for targeted decisions. Previously these decisions would check every country in the world every day, and with some of the more complex triggers that could amount to quite a bit of number crunching. With the new features, we can pre-restrict the list of targets to reduce the necessary number of checks. Unfortunately, the new script features came too late in development for us to utilize these features in the initial release and other bugs took priority.

Thankfully, a member of the community by the name of Antoni Baum (aka “Yard1”) did make the effort to go through our script and fix all the places where the new features would make a difference (as well as a few triggers where a small reordering of script checks resulted in better performance). This work has been merged into 1.7 with permission. While it is difficult to measure the immediate performance effect of these changes, we saw a performance improvement of about 5-10% depending on the overall gamestate, number of wars etc.

We planned to put 1.7 out as an opt-in beta tonight but we hit some snags (which is why this diary is a bit late ;)) but we think we should have the open beta tomorrow with patchlog for those brave enough to help us test it :)

See you again next week!
 
I'm not sure there's any feeling in the world of software development quite as good as getting rid of a piece of legacy code that has been a lingering problem. :)
I'm actually surprised that there is something so old. Was this from HOI1 or something written when HOI2 was being made? It makes me wonder what other old code is governing game mechanics.
 
I'm actually surprised that there is something so old. Was this from HOI1 or something written when HOI2 was being made? It makes me wonder what other old code is governing game mechanics.
It might not be that old, it might just be old in terms of HoI4 (e.g. one of the first things they wrote).
 
It might not be that old, it might just be old in terms of HoI4 (e.g. one of the first things they wrote).
Well, podcat did say from 2003, so that's why I wrote from HOI1, or HOI2. Using code from 16 years ago, I mean, I thought only Bethesda did that . . . .
 
Midway is overly cited on these forums by carrier fanatics that want carriers to destroy everything quickly.

If you take a closer look at Midway, the lesson to be learned is the value of air cover. The Japanese CAP was composed of a small number of lightly armed A6M2 Zeroes yet they were able to shred wave after wave of US bombers until sheer numbers overwhelmed their interception capability. Imagine what a large force of land based long range advanced fighters such as the P-47N or Spitfire Mk24 could do to the bombers of a typical carrier air group.

In the case of Midway they could have done nothing at all since the battle was fought so far away from Japanese land bases that no airplane had enough range.

In general it was very hard to coordinate land based air from the airforce or army with fast moving Navy taskforces. Then there is the question of reaction time, frequently fighters on the carrier deck could scramble and intercept within the 5-15 minutes from detection of an incoming strike until it dropped it's ordnance. Good luck with achieving that when the fighters are 3 hours flight time away..

Practical wartime experience showed that a fighter on the Carrier was worth more for it's defense than 50 fighters on a land airbase some 300 miles away.
 
fix the air ui
 
Well, podcat did say from 2003, so that's why I wrote from HOI1, or HOI2. Using code from 16 years ago, I mean, I thought only Bethesda did that . . . .
A lot of companies actually tend to use legacy code. The thing about legacy code is it already exists and does some of the job you want to do. And well, the thing about replacing it with modern code? That takes things called time and money. 2 things a executive hates spending more than anything else. They might just force you to use the legacy code because in their own mind, you have the code already, so you dont need to replace it. And that is wen you are lucky enough that the code can be so easily replaced. Often, replacing legacy code means reworking a very large chunk of the entire program because vital features are actually dependent on the code, meaning it quickly goes from being a replacement of legacy code to being a major redesign of the product. At least in gaming however, you are fortunate enough that a large chunk of legacy code has to be removed overtime by the need to constantly work well on the modern PC or console.

Because you think that 2003 legacy code is old? The cash registrar is running a program that was likely made in either the 90's or 80's and would struggle to run on a 32 bit computer. The self-checkout is likely running a more advanced program by sheer virtue of being created more recently.
 
What part of it do you think is broken?
The squadron creator is extremely unwieldy, tiny window and no filters at all.

There's also no way to tell a squadron to not reinforce (or not reinforce until a certain % of planes are gone).
 
Soviet battleship Marat was sunk by Stukas carrying 1000 kg AP-bombs. Lighter bombs did not have enough penetration. That info according to Rudel, who sank it.
Tirpitz was sunk by special bombs carried by RAF strategic bombers (too heavy for CAS to carry).
Were other BBs lost to bombs only, without torpedoes?
Yamato and Musashi got a lot of hits by both before sinking.
 
The squadron creator is extremely unwieldy, tiny window and no filters at all.

There's also no way to tell a squadron to not reinforce (or not reinforce until a certain % of planes are gone).

OK. I wouldn't call that broken though, but your right that there is room for improvement in both those areas. I would prefer flexibility like we have with divisions, where you can tell air-wings exactly what equipment they are allowed to use.
 
The squadron creator is extremely unwieldy, tiny window and no filters at all.

There's also no way to tell a squadron to not reinforce (or not reinforce until a certain % of planes are gone).
Yeah, room for improvement but several other key things need to be added to HOI4 to improve realism/reality rather than reworks just for QoL purposes....IMO.
 
When it comes to regular combat we wanted to help out carriers and capital ships a bit and we felt the more realistic way of doing that was to give them a time at the start of the combat when they are the only ones active. Carriers and aircraft are active straight away. Some ticks later capital ships and subs get to fire and last screens. This gives a bit of a boost to those bigger ships and represents their longer ranged weapons better.
Are those bits modable? I.e. I'd like to model late-war ballistic computers giving an edge with a few extra ticks of shooting. Also there's got to be certain difference between various capital ships themsevles.
 
Are those bits modable? I.e. I'd like to model late-war ballistic computers giving an edge with a few extra ticks of shooting. Also there's got to be certain difference between various capital ships themsevles.
It’s not mentioned in the patch notes so I doubt it made it in this beta. But yeah, those tick counts need to be moddable.
 
Oh, come on. Still no fix of fire control systems, turning ships into glass cannons?

The penalty has been halved in the open beta to address this issue. Give it a try and let us know what you think!
 
I'm actually surprised that there is something so old. Was this from HOI1 or something written when HOI2 was being made? It makes me wonder what other old code is governing game mechanics.
It doesn't matter exactly how old it is, it still feels great to get rid of code you don't like. :)
 
A lot of companies actually tend to use legacy code. The thing about legacy code is it already exists and does some of the job you want to do. And well, the thing about replacing it with modern code? That takes things called time and money. 2 things a executive hates spending more than anything else. They might just force you to use the legacy code because in their own mind, you have the code already, so you dont need to replace it. And that is wen you are lucky enough that the code can be so easily replaced. Often, replacing legacy code means reworking a very large chunk of the entire program because vital features are actually dependent on the code, meaning it quickly goes from being a replacement of legacy code to being a major redesign of the product. At least in gaming however, you are fortunate enough that a large chunk of legacy code has to be removed overtime by the need to constantly work well on the modern PC or console.

Because you think that 2003 legacy code is old? The cash registrar is running a program that was likely made in either the 90's or 80's and would struggle to run on a 32 bit computer. The self-checkout is likely running a more advanced program by sheer virtue of being created more recently.

It doesn't matter exactly how old it is, it still feels great to get rid of code you don't like. :)
No argument from me. I know why they used it, I'm just surprised to hear it. It's like watching some documentary about how things you use everyday are made. It's interesting, and some of it surprising.