• 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.

HOI4 Dev Diary - Tech bugaloo II - Dragonslaying

Hi guys! Today's Diary is going to be a bit of a short one as I am away at a conference (it has free breakfast! Two most magic words!)

Last week we celebrated HOI4’s 3 year anniversary and released 1.7 ‘Hydra’ along with Radio Pack and Axis Armor. I hope you enjoyed them :)

After the weekend we looked at our telemetry data after 1.7 released and noticed that the amount of multiplayer out of syncs were more common than before. This indicates that we introduced a new OOS problem. While HOI4 has resync and hotjoin its still pretty annoying when you out of sync so we are currently investigating this for a small hotfix patch (1.7.1). Out of syncs can be really tricky to find and nail down so no definite ETA yet on when the patch is ready as we are still hunting. But we acquired a solid lead on the problem just yesterday, and we're currently working out a good solution.

Technical section (warning!): What is an Out of Sync?
For those interested what an out of sync is I figured I’d dig into it a bit. Feel free to skip this if you are a... normal human being, I guess ;D

An Out of Sync (OOS) happens when the host and clients in a multiplayer game start acting differently. This could for example be something like a battle ending in the favor of Germany on one of the computers and in the favor of Soviets on the other. Usually though its nothing that big as the state difference is usually spotted earlier at say one of those units having a 1% higher organization than the other or the like. Once it happens everyone’s experience will very quickly start diverging, so we stop and alert the players. At this point the host can click a ‘Resync’ button to bring the game back into sync. Resyncing will reset the state of the game, send the current host state over as a savegame and have everyone load that, and then things can resume.

So what can cause an OOS? This is where it gets tricky, and its pretty much always a new reason when a problem appears. Some good candidates are multiplayer between different platforms because underlying code libraries can behave differently in some cases. Other common reasons are multithreading. We thread a lot of our code, yet to stay in sync we must assure that events still happen in the same order on all machines in the end if they affect the world. There can also be issues like touching illegal memory or the like that can alter the game state in unplanned ways (or crash… but those are easy to spot and fix!).

Finding and fixing an OOS can be a long process simply because they are often quite rare occurances and it usually takes many steps and iteration to home in on exactly what it is. To find them we run multiplayer tests with QA with special settings that spit out giant log files (which makes everything horribly slow generally) and once and OOS happens we compare log files and savegames to see what differs. This will usually give us an area to start looking at. Lets say for example that you have a unit’s org being different. This could be due to many reasons - battle damage, weather, bad supply etc. So we add more logging to the relevant code areas and do another test. Hopefully this will tell us which of our guesses was right, and we repeat again with more logs and more details for this area. Of course the most fun-to-find OOS errors disappears when you add logging and framerate slows ;P

Some of this can be done automatically over night as well if the problem is unrelated to players, but this is often not the case.

Once found and fixed this is usually the stage we make an open beta patch to verify that it is indeed fixed, or if we deem it sure that we found the problem we will go straight to regular patch. Speaking of beta patches, thanks for the help testing 1.7! we got something like 30k game sessions of testing on the weekend before the final build which was a great help!

Hopefully this little look into some of the technicalities behind working on HOI4 was interesting. If you got questions feel free to ask away!

The part of the team that isn’t trying to solve this OOS has now moved fully on to 1.8 ‘Husky’ and next expansion work, but its early days and its going to be a while until we have things to show off. So this will be the last dev diary in a while as we go into radio silence (and soon glorious socialist swedish summer vacation!) until we have things that are ready to show off.

See you on the other side! And keep an eye on the forum for announcement about the 1.7.1 hotfix when that is ready.
 
Last edited:
Next expansion better be commie themed with Russia and Spain.
 
Probably a Mediterranean rework; my bets are Spain, Greece and probably an Italian rework, hopefully with some espionage stuff aswell.

Generally I think the Devs are doing a SOV rework, as the community has been very disappointed in SOV's ability to resist and beat GER. However, I don't know what the other trees will be. It will most likely possibly be GER. communist as the other major rework with Finland and Sweden OR Norway as the minor's focuses.
 
Generally I think the Devs are doing a SOV rework, as the community has been very disappointed in SOV's ability to resist and beat GER. However, I don't know what the other trees will be. It will most likely possibly be GER. communist as the other major rework with Finland and Sweden OR Norway as the minor's focuses.
If I was doing a SOV rework and only allotted one DLC rework to each tag, I'd choose France as the other major, as they both had the next strongest far-left and were similarly in a position of being an inevitable target of German revanchism.
 
If I was doing a SOV rework and only allotted one DLC rework to each tag, I'd choose France as the other major, as they both had the next strongest far-left and were similarly in a position of being an inevitable target of German revanchism.

France would indeed be a good second option, but I think it would fit better with an Italy and Mediterranean expansion.
 
France would indeed be a good second option, but I think it would fit better with an Italy and Mediterranean expansion.

I think that surley accompaying the very pressible the soviet rework the most logical would be accompanied by polish rework because surely communismm will have its own puppet system as the fascist did as democratic. i think they will come accompanied with shared formula o semi shared approaches of Baltic and Scandinavian countries including Denmark .
 
I think that surley accompaying the very pressible the soviet rework the most logical would be accompanied by polish rework because surely communismm will have its own puppet system as the fascist did as democratic. i think they will come accompanied with shared formula o semi shared approaches of Baltic and Scandinavian countries including Denmark .

I don't think there will be a puppet rework for Communism. However, I did totally forget Poland! RIP Poland. Best guess, Focus trees for Scandinavia (Sweden, Finland, Norway, and Denmark) a rework of USSR and Poland, with new mechanics in intrigue and partisans. Poland would fit, with Cyclometer and it leading the Cracking of the Enigma System. While Sweden will get flavor as intrigue capital in Northern Europe.
 
There's no DD yesterday?

Nope but they did release a new beta patch

Thanks to all the players trying MP sessions on the open beta! The out-of-sync bug fixed last week appears to have been the big one introduced in 1.7.0.

We have an update to the open beta 1.7.1_beta with some balance tweaks to field marshal/general traits, and a fix for certain ship module speed penalties being way too big.

The checksum is f8d7

Here is the changelog:
##################################
# Balance
##################################
- Lowered scaling of defense stat to 2.5% per level from 5%
- Reduced org loss when moving from offensive doctrine field marshal trait
- Increased planning speed bonus from fast planner field marshal trait to 25% from 10%
- Added breakthrough modifier to aggressive assaulter field marshal trait
- Reduced attack bonuses in cavalry leader trait from 15% to 10%
- Reduced infantry defense bonus from infantry leader trait from 15% to 10%
- Reduced terrain penalty reduction from adaptable trait from 50% to 30%
- Increased acclimatization to cold factor in winter expert trait from 20% to 40%
- Reduced attack bonus on rivers from engineer trait from 10% to 5%
- Reduced defense bonus of panzer expert trait from 15% to 10%
- Reduced cavalry defense bonus to 10% from 15% and removed attack bonus in cavalry expert trait
- Reduced attack bonus vs forts to 15% from 20% in fortress buster trait
- Reduced infantry attack bonus from 15% to 10% in infantry expert trait
- Reduced entrenchment bonus from 10 to 5 in the ambusher trait
- Reduced supply consumption marshal trait from 20% to 15%
- Reduced out of supply factor on commando trait from 50% to 25%
- Increased dig in speed from guerrilla fighter trait from 25% to 50%
- Fixed the naval module speed penalties for depth charges, aircraft launcher, and mine sweeper which were 10 times larger than intended.
 
I am not from Sweden, but as far as I know all Scandinavian countries have long Summer holidays. So I guess end of July or some day in the first half of August.

I know...
I was critiquing the ambiguity of the given statement, hoping to get "we'll fix the essential stuff before that" or "yes, mid August". Even a simple "yes" or "no" would work.
 
Are u-boat III hulls still to powerful to allow in mp games?

We are still testing it in a game right now, but I am beginning to think that either the hulls are too strong in general, or that there are issues with other mechanics related to submarines.

For example, in the current MP game we have, we slashed torpedo values for all torpedoes on u-boats by around half in response to the change where u-boats fire while retreating.

This is the result:

342s8m.png


And despite the UK's best efforts (and the UK is really focusing on convoy protection and looking for subs, I might add; he sank a bunch of my old subs with NAVs while I wasn't looking), I don't think a single 1940 submarine of mine has been lost outside of being detected in convoy battles when torpedo reveal chance reveals one. And that's the performance with a nerf to torpedo attack values. If I had vanilla torpedo values, there literally would be no convoys left to sink at this point.

The question to me is what, exactly, is wrong here. It could be that visibility or detection values are off. But I have a different hypothesis that I need to test once I have more data from the current MP game. I suspect there may be a flaw in the actual detection system. As in, the game should have value X from input Y, but a bug is causing value 0 from input Y.

But that's just a hypothesis. I've been wrong before.
 
We are still testing it in a game right now, but I am beginning to think that either the hulls are too strong in general, or that there are issues with other mechanics related to submarines.

For example, in the current MP game we have, we slashed torpedo values for all torpedoes on u-boats by around half in response to the change where u-boats fire while retreating.

This is the result:

342s8m.png


And despite the UK's best efforts (and the UK is really focusing on convoy protection and looking for subs, I might add; he sank a bunch of my old subs with NAVs while I wasn't looking), I don't think a single 1940 submarine of mine has been lost outside of being detected in convoy battles when torpedo reveal chance reveals one. And that's the performance with a nerf to torpedo attack values. If I had vanilla torpedo values, there literally would be no convoys left to sink at this point.

The question to me is what, exactly, is wrong here. It could be that visibility or detection values are off. But I have a different hypothesis that I need to test once I have more data from the current MP game. I suspect there may be a flaw in the actual detection system. As in, the game should have value X from input Y, but a bug is causing value 0 from input Y.

But that's just a hypothesis. I've been wrong before.
keep me posted on the conclusion plesase ;)