Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
This is not completely correct. I have written a lot of multi threaded code and multi threaded code used for multiplayer. The desync issue is definitely true and hoi 4 does only really use 1 or 2 threads well with the rest of them doing unimportant tasks. But what is not true is that older cpus ran hoi 4 faster. The current cpus we have have much faster cores and many more of them. If you really think your older computer ran hoi 4 faster it is most likely not that the CPU got slower, but the recent updates of hoi 4 are slower.
In a simulation game like hoi 4 there is usually a set of steps that must happen in order for the simulation to progress every tick. On a single thread you just complete the steps in order but on multiple threads you can't just do all the steps at once each on different threads because step 1 must complete before step 2 and it is possible that step 2 is faster to complete.
For example you must calculate supply before battles because the supply factors into the battle so they can't be done on different threads. You would likely have to split the supply and battles into different regions like continents that different threads handle at the same time but that would still bring up the issue that one continent may finish faster relative to another, changing your equipment stockpiles and manpower and such, while on another person's computer the other continent may finish first leading to desync. The simulation must lead to the same outcome every time to avoid desync. There is tricks to work around these things but that would require a new engine.
Why would it?
Thanks for all the useful links, the guys at paradox talking about it is a really outstanding addition to this thread topic :)
Honestly this thread has a lot of outstanding information being posted. Makes me wonder if Im really on steam. xD
Im so used to
"You cant change software"
"Download more ram"
"Alt F4"
"Editing the settings is super l33t hacks"
"If you see imperfections , you must hate the game and you have to stop playing, how dare you suggest improving anything"
"Im going to reply to your question be restating it, and pretending that a solution"
So, I just want to thank you all for those incredibly in depth and relevant posts, and the decent posters too :)
There is plenty o stuff that doesntn eed to be exactly syncrhonized, diplomacy, supply, manpower and PP calculation , really the only thing i can think of off the top of my head is combat, and I suppose movement, cause that makes a big difference on combat starting and who wins getting where first,ect. There is so much leeways for loose sychronisation . Im curious to hear what was said in that video link, I think ill watch it now :)
but why would that have any effect at all on multi player? Isnt it all calculated on the host machine?
No not fully at least because that would require the host to update and then send the entire game state to other computers which would use way to much internet connection. I do think that the host does do this partially though because often times I find that much slower cpus keep up with much faster cpus in multiplayer so they obviously aren't doing the same calculations. Also desync wouldn't be possible if it was all calculated on the host.
Isnt that why the host is often weeks or months ahead of the other players?
I suppose that makes sense, unless they did something really stupid.
However, anything that uses the RNG either needs to be executed in the same order on all machines (so no multi-threading) or needs to be executed on a single machine.
Cant really argue with that point. :)