First up, I've just asked the moderators to move this whole conversation into a separate thread in the Advanced Civ subforum. It's conceivable that it'll be of interest to some third person, but not for most players.
a. how did you managed to execute ai auto play in an mp play?
I did it in singleplayer. Just in case that it's an issue with uninitialized memory or synchronized data not getting saved (and that it occurs commonly enough to come up just like that). If it can be addressed in singleplayer, then that's much more convenient than having to juggle multiple instances.
If I know that AI Auto Play (in singleplayer) will diverge if I run from a particular savegame for, say, 200 turns, then I might reload the save and try 100 turns next, then 50 or 150 ... – until I find an autosave from which AI Auto Play will yield inconsistent results within a few turns. From there, ReproTest can be used to find out after which turn exactly an inconsistency occurs (can be hard to tell from just looking at the map; ReproTest checks the entire game state) and how the two game states differ. Well, I don't think you're in this situation. There are instructions in
ReproTest.h,
AI Auto Play can be used in multiplayer too; that's a different kind of test, but also potentially helpful. This requires ENABLE_AUTOPLAY_MULTIPLAYER = 1 in GlobalDefines_devel.xml. There's also ENABLE_DEBUG_TOOLS_MULTIPLAYER for Debug mode and WorldBuilder; please see the description in GlobalDefines_devel.xml about that.
b. i ran manuall around a hundred turns on my 2 instances of civ. couldnt get oos.
That's also a useful (albeit tedious; but it's all tedious ...) way of testing. The AI will make offers this way that wouldn't come up in AI Auto Play.
c. "Ottoman revolt in New York" - you mean that its not synced or synced and just an example where you reached?
Getting this unusual event after exactly 300 turns both times strongly suggests to me that both AI Auto Play runs were in-sync. So no problem was evident from this test. Of course this isn't to say that the problem must lie with DotO; it could well be something in my code.
can oos happen due to some hardware issue? maybe network hiccup or something?
I doubt it. I imagine that the CvNet... messages are sent over TCP, which should all but guarantee delivery.
didnt see these logs - where am i to look / or define something in the bbai.h
CvEventManager writes to PythonDbg.log. The BBAI log requires a recompile after uncommenting
//#define LOG_AI.
its something you changed or darkLuna in the ooslogger right? i read some of the file. [...]
anyway for my next session, ill make sure that both of us have all the logs on.
The OOSLogger has always checked CyInterface().isOOSVisible(), i.e. whether the game is actually out of sync. I've added the MessageLog check because, if a game is continued after an OOS error, a player could inspect the log and see some information that is supposed to be secret. (That's a pretty farfetched way of cheating, so perhaps the log should be written regardless of the MessageLog setting.)
let say, i get the plot example,
what then - how one can reverse engineer it to the source?
If that unit being in the wrong spot is the only difference, then you might check its UnitAI type in Debug mode (after going OOS and, to be on the safe side, also in the autosave on the turn before), then look at the respective CvUnitAI routine, say, AI_pillageMove if the AI type is UNITAI_PILLAGE. If there are additional logs to compare, then that could get you closer. For example, if "AI Patrol" is the last in-sync RNG call in MPLog.txt, then it would seem likely that the error occurred in or after AI_patrol. If the error is reproducible with two instances on a single PC, then you can set a debugger stop in AI_patrol and step through the code, first with the debugger attached to the one process, then, after restarting and reloading, to the other process. If you take too much time in the debugger though, i.e. longer than a few(?) seconds, the network connection times out.
i wonder what in theory could bring the oos from my additions.
maybe i should examine some soren andom i might have added?
The RNG calls themselves aren't all that error-prone. One mustn't call a synchronized RNG (SorenRand, MapRand) in a non-synchronized context and mustn't change synchronized game state based on the outcome of a non-synchronized RNG call (ASynchRand). A more common error is to change synchronized game state of the ActivePlayer (or ActiveTeam). All this would lead to reproducible errors though (with two instances on one PC). The state of the (supposedly) sync'd RNGs is the first thing that goes into the OOS checksum
Code:
int CvGame::calculateSyncChecksum()
{
int iValue = 0;
iValue += getMapRand().getSeed();
iValue += getSorenRand().getSeed();
// ...
}
and that's what causes the game to declare that there is an OOS error. No randomness involved.
i really like the music of civ.
"If you're talking to Saladin, then who am I talking to?"
Well, it's probably not going help anyway.
