Dis Citsatnaf
Chieftain
- Joined
- Oct 2, 2011
- Messages
- 17
Edit: TL;DR: both 0.41o vanilla and More Naval AI 1.7 DLLs that seem to make ffh2 work with pitboss and MP hotjoins is linked at the bottom of this boring, technical post.
Hello there (long time lurker, etc),
We've been trying to get a pitboss game of FFH2 up, and ran into the issue (familiar in hindsight from normal MP) where any hot-joining player will go OOS with the rest of the p2p mesh, including the pitboss 'player' (who keeps his own sync and options checksums.)
After filling CvGame.cpp up with debugging output, it turns out that the culprit APPEARS to be the following line in CvCity.cpp:
m_iCrime = GC.getGameINLINE().getSorenRandNum(20, "Crime");
which is called in CvCity::init, including when the connecting client has deserialized the game (including the random seed,) and is creating its own CvCity objects, even though the other players ran this code when the city was built (and the 'correct' crime value was already deserialized from the p2p mesh.) In other words, RNGs are being called non-synchronously.
I'm sure there's a better fix here (maybe moving the getSorenRandNum call to somewhere it's guaranteed to be executed synchronously), but changing it to
m_iCrime = 0;
is a guaranteed to be synchronous and seems to work. I'm not sure what the ramifications of every city starting with a base crimerate of 0 are to gameplay, but my understanding is that crime is mostly a flavour mechanic in any event, and the utility of being able to hot-join MP games outweighs it, at least for me.
Here are pre-compiled DLLs with this change (against 0.41o, and Tholal's Naval AI mod 1.7) if anyone wants them. I'll probably have another look at the code later and try and find a better spot to randomize m_iCrime (such that the code isn't called during deserialization), if anybody wants to have a crack at that, be my guest.
/S
Hello there (long time lurker, etc),
We've been trying to get a pitboss game of FFH2 up, and ran into the issue (familiar in hindsight from normal MP) where any hot-joining player will go OOS with the rest of the p2p mesh, including the pitboss 'player' (who keeps his own sync and options checksums.)
After filling CvGame.cpp up with debugging output, it turns out that the culprit APPEARS to be the following line in CvCity.cpp:
m_iCrime = GC.getGameINLINE().getSorenRandNum(20, "Crime");
which is called in CvCity::init, including when the connecting client has deserialized the game (including the random seed,) and is creating its own CvCity objects, even though the other players ran this code when the city was built (and the 'correct' crime value was already deserialized from the p2p mesh.) In other words, RNGs are being called non-synchronously.
I'm sure there's a better fix here (maybe moving the getSorenRandNum call to somewhere it's guaranteed to be executed synchronously), but changing it to
m_iCrime = 0;
is a guaranteed to be synchronous and seems to work. I'm not sure what the ramifications of every city starting with a base crimerate of 0 are to gameplay, but my understanding is that crime is mostly a flavour mechanic in any event, and the utility of being able to hot-join MP games outweighs it, at least for me.
Here are pre-compiled DLLs with this change (against 0.41o, and Tholal's Naval AI mod 1.7) if anyone wants them. I'll probably have another look at the code later and try and find a better spot to randomize m_iCrime (such that the code isn't called during deserialization), if anybody wants to have a crack at that, be my guest.
/S
and some of the cities of my mates.
