Yes any of the above is possible I suspect (except opportunity fire anyway - that does a sync roll to determine if it hits, and that would show up as one side performing an opportunity fire roll, and the other not, which is not in the logs)
Multi Player bugs and crashes - After the 16th of May
- Thread starter Dancing Hoskuld
- Start date
Yes any of the above is possible I suspect (except opportunity fire anyway - that does a sync roll to determine if it hits, and that would show up as one side performing an opportunity fire roll, and the other not, which is not in the logs)
When I tried it it worked fine. As khh says only one side needs to listen for a connection.
You need to add "multiple" (without "") as command line argument to the shortcut.
Thunderbrd
C2C War Dog
We'll turn it back on and send you what we get later today. I was busy with the bug-spray last night myself.
Stormwind
King
- Joined
- Dec 7, 2008
- Messages
- 697
OOS with the logs from both PCs and savegame. Rev 5568. Are only OOSlog, randomlog and BBAI logs needed or provide the other logs additional information?
View attachment 352611
View attachment 352611
Random logs needed please always for OOS analysis. BBAI logs can also be useful (depends what it is)
Logs (random, OOS, BBAI) from an OOS involving a combat versus an invisible unit. Using the latest SVN with the multi-threading.
Edited to add: Adding another set of logs. It didn't create an OOS log (though it went OOS at the beginning of the turn) but attaching the random and BBAI logs.
Edited to add: Adding another set of logs. It didn't create an OOS log (though it went OOS at the beginning of the turn) but attaching the random and BBAI logs.
This looks like the previous one - units apparently entering combat with different stats, resulting in different combat paths (and consequential rand de-syncing). It is 99.99% certainly not related to the multi-threaded city processing, so it's not really my area, or the issue I am focussed on right now (which is OOS due to the city processing).
@AIAndy - I think this is just a long running existing OOS issue - can you tell anything more precise from the logs than the above? (OOS log shows health of a unit difference, but I'm not sure if that is as a result of the combat desync, or the cause of it). BBAI logs don't show anything obvious
Given the differing combat path the only explanation I can see is different starting strengths (because 'iAttackerCombatRoll < iAttackerHitChance' passes on one machine and gives the attacker a round to process, but doesn't on the other). This could be due to an incorrect use of an async rand somewhere (e.g. - in promotion choice decisions), but I can't see one...
One more combat round is likely to make a difference in the health so I assume it is more likely that it is the result of the desync and not the cause.
I think we should include more information in both the sync checksum calculation (CvGame::calculateSyncChecksum) and the OOS log.
Especially the information which promotions each unit has so any difference in promotions causes a desync when it happens and not only when the promotion makes a difference in combat or anything.
Agreed - I think the state dump in the OOS log looks like the right place (to list promotions). I'm rather snowed under with work on making more of the city pipeline asynchronous right now though, so I may not get to it for a while. Let me know if you get there first...
I'll do it.
Edit: Done. The revision I just committed has the promotions added both to the sync checksum and the OOS log.
Thunderbrd
C2C War Dog
@Koshling... I just sent you some logs from last night's playtest with the multi-threading back on. It did of course go OOS after loading and hitting the end turn.
Stormwind
King
- Joined
- Dec 7, 2008
- Messages
- 697
Rev 5578. Second OOS on the second combat in the game. Logs from both PCs and savegame attached.
View attachment 352763
View attachment 352763
See email - they don't seem to be from the most recent version (logs are still the old format ones)
Edit - Falcon's are, so it's definitely not a problem with the logging code
Thunderbrd
C2C War Dog
That's odd since we generated those logs on Saturday night. We'll try again later...
I have found a definite problem from these logs. Next time I make a push to the SVN a fix (for the issue I can see - can't guarantee its the only one by any means!) will be included.
The main weird thing I see is that the city name is not properly logged in the random log there.
One city seems to have Religion Spread rolls on one computer only and it might well be the same player 2 city that later builds a wanderer on the computer of player 1 but nothing on the computer of player 0.
The cause of the OOS is the sync'd rand thrown by CvUintAI::AI_init() on unit initialization, which is using the global stream, but occurring on city training of units (which is multi-threaded). The lack of city names as stream names is also concerning - I'll sort both out.
Edit:
Oops:
Code:
virtual const wchar* GetName(void) const
{
return m_pCity->getName().c_str();
}returns a pointer to an object it then implicitly destructs. My bad.
While that certainly is something to fix, I don't think it is the actual desync reason here.
The birthmark is only on one computer because only one computer built the unit while the same player 2 on the other computer decided to build nothing (the OOS log shows nothing produced on the computer of player 0 while on the computer of player 1 the city first produced a wanderer and then is currently producing some building).
So the actual action that desynced the game probably happened on turn 17 or turn 19 which shows a bunch of random rolls on one computer only each and at least the second has to do with AI building decisions.
Given the stream names are all NULL are you sure they are not in order within each stream (or at least that that is the first thing that isn't)? With the bugged stream names I don't think there is much clarity here - best just get another set once that is fixed I think.
Similar threads
- Sticky
- Sticky