Thunderbrd
C2C War Dog
I'll be happy to look into it tomorrow but since I have a lot more faith in your abilities, don't let that stop you from doing what you can either if you've got the time for it. 
Multiplayer Woes
- Thread starter DocCox
- Start date
I'll be happy to look into it tomorrow but since I have a lot more faith in your abilities, don't let that stop you from doing what you can either if you've got the time for it.
Leave I with me. I have to fully understand it anyway to figure out why it brekas performance in the test case I have and address. As AIAndy says, it's almost certainly a bad parameter usage in a call somewhere, since his change seems entirely reasonable.
Edit - ok got it. Some calls had two booleans the wrong way around, and were passing async=true, norand=false, from a context that is frequently used and normally synchronous, but occasionally asynchronous (so it was intended to pass noRand=true). I'll push the fix with my next checkin (which will be large) once I verify all the performance characteristics are back where they should be, and finish debugging generally.
Thunderbrd
C2C War Dog
Awesome! Well done Koshling! 
Thunderbrd
C2C War Dog
OK, You guys are both amazing... we went about 50-100 turns last night with NO OOS ERRORS!!!
A lot of the earth evolution crew who play on gamespy in big mp games have recently gotten into c2c & ROM AND, they like c2c for SP but think its too long for MP (which I kinda agree with). However, ROM AND seems plagued with OOS issues.
I was wondering, are there any simple OOS fixes that were applied to c2c that can easily be stuck into ROM AND, and by simple I mean something that a total noob can do (like me) lol.
Even if its maybe not that easy, if you could point me in the right direction and I could pass on this wisdom to someone who might have a chance of doing it - that'd be great.
I was wondering, are there any simple OOS fixes that were applied to c2c that can easily be stuck into ROM AND, and by simple I mean something that a total noob can do (like me) lol.
Even if its maybe not that easy, if you could point me in the right direction and I could pass on this wisdom to someone who might have a chance of doing it - that'd be great.
You could check the SVN changes that say in the comment that they fix sync or oos issues but I doubt you will be able to properly apply them without understanding what they actually do.
Thunderbrd
C2C War Dog
We did find another OOS error but for whatever reason, my wife's computer was giving her reporting errors and did not record the OOS log. What can I do to try and figure out why her machine gave an error/fail and mine did not?
Did it write a PythonErr.log?
Thunderbrd
C2C War Dog
I just checked... yes!
Then post it please.
Thunderbrd
C2C War Dog
Ok... was trying to get it to you before I left for work but it didn't upload fast enough so now it'll have to wait til I get home.
Thunderbrd
C2C War Dog
It seems like BugPath fails to find the folder with your CivilizationIV.ini (you can see the error message in your PythonDbg.log) and I use that as base to find the Logs folder to write the OOSLog in.
Can you investigate what exactly fails in initRootFolder in BugPath.py?
Thunderbrd
C2C War Dog
Wouldn't have a clue how to look into that (python stuff). But I can say that she must've done something wrong because her ini settings were all reset when she went to reload. Do you think that somehow the file had been erased and then rebuilt when she reloaded?
Ever since I learned what the ini file was and how to adjust it, I've often found ini file settings switching back to defaults on occasion. Perhaps it was nothing she did so much as something happening on occasion that erases the ini file, perhaps even during a game. If that's the case and it happened to her this time, it wouldn't be surprising we'd show this error at some point.
But apparently this OOS problem is rare as we played for another few hrs last night without issue.
Mainly check PythonDbg.log to see if it still reports an error that it can't find the root directory. If it was a one time happening that it does not find the root dir, then that is ok but if it happens repeatedly it is something that needs to be fixed.
Thunderbrd
C2C War Dog
So just keep tabs on it then? Fair'nuff. I'll let you know if it seems to happen more often.
That has been perpetually happening to me for four months now. I assume it is a game engine bug, but if anyone has ideas on how to fix it that would be appreciated, I hate having to reset my ini file every couple weeks.
Thunderbrd
C2C War Dog
I haven't had a chance to look at the PythonDbg.log yet but this same thing took place again last night. So yeah, we may have a bigger issue than the ini file randomly deleting and rebuilding itself.
Interestingly enough, I had a CTD on my system the round after. Happened late so I haven't built a debug dll to evaluate the minidump with yet.
Its not happening all that often so its tolerable at least.
Hello, here to report another OOS error.
I don't know if this gives much help on locating the problem in the code, as the problems we are having seem to be misplacement problems of units or having different production coming up in a City. Or atleast so I understood when comparing turn logs.
These errors are however becoming more constant each turn and are becoming unbearable. These can be skipped by reloading the save(the save taken when the OoS occurs, sadly we didnt realize that we should have used the autosave feature) after restarting the game.
The first 300 turns went without much of a problem, but after that OoS happened every 20 turns, and now every 2 turns. Wondering if there is any solutions or if the mod is just currently unplayable with all these features on or/and with this huge map? The version is svn 4028.
Here are both of the player logs, included all the possible logs and minidumps as I'm not sure what are relevant.
I don't know if this gives much help on locating the problem in the code, as the problems we are having seem to be misplacement problems of units or having different production coming up in a City. Or atleast so I understood when comparing turn logs.
These errors are however becoming more constant each turn and are becoming unbearable. These can be skipped by reloading the save(the save taken when the OoS occurs, sadly we didnt realize that we should have used the autosave feature) after restarting the game.
The first 300 turns went without much of a problem, but after that OoS happened every 20 turns, and now every 2 turns. Wondering if there is any solutions or if the mod is just currently unplayable with all these features on or/and with this huge map? The version is svn 4028.
Here are both of the player logs, included all the possible logs and minidumps as I'm not sure what are relevant.
Thunderbrd
C2C War Dog
Some more OOS logs. Apparently her computer doesn't ALWAYS throw the ini file - it just so happened to do so twice. But there is an interesting anomaly on the python logs regarding a module being loaded by one but not the other.
Also, again, the random log seems to show that the random goes off course during ai defensive evaluations. Something leading to that point apparently is still going non-deterministic.
Side note, the rev version on these has not changed since I updated after the last OOS fix. They have grown increasingly frequent again and it ends up happening turn after turn once more.
Here's the logs!
I keep watching these fixes in the code, learning a little more every time. But it does help that you've been explaining your processes in fixing these. I feel like I'm beginning to have a shallow understanding on some of it. What really got me on the first fix was having no idea HOW you found the problem there in the first place!
Also, again, the random log seems to show that the random goes off course during ai defensive evaluations. Something leading to that point apparently is still going non-deterministic.
Side note, the rev version on these has not changed since I updated after the last OOS fix. They have grown increasingly frequent again and it ends up happening turn after turn once more.
Here's the logs!
I keep watching these fixes in the code, learning a little more every time. But it does help that you've been explaining your processes in fixing these. I feel like I'm beginning to have a shallow understanding on some of it. What really got me on the first fix was having no idea HOW you found the problem there in the first place!
Similar threads
