It is zipped but about 30MB. I am not at home so I could not look at it yet but it is usually the random log that gets that big. I only really need the last part of it as the files do not differ before the OoS happens so about one turn of random log is enough.
Multiplayer Woes
- Thread starter DocCox
- Start date
I did and the report went from 500MB to 34MB, still too big.
Thx for the advice, will do so in the future.
The only difference in the OOS logs is that in one the great general has 4xp and in the other he has 3.Tried the fix and it works, kudos.
We started using SVN and only had 1 OOS after playing 5 hours.
The OOS report were too large for attachment so I published it on MediaFire:
http://www.mediafire.com/?ajit4ctb4b8n4qw
This one happened when a British Stone spearman attacked my roman javeliner and won on the first end turn of the save, the OOS could also be connected to the British great commander who fled the scene of the action.
A first investigation of the code did not yield an easy reason. It might have something to do with commander caching.
Might this be related to the other GC xp issue reported today?
Possible. Further investigations will show.
hm.. i started pitboss and game on one machine
and game gave me OOS and error
TRACE: Error in gameUpdate event handler <bound method RoMEventManager.onGameUpdate of <RoMEventManager.RoMEventManager instance at 0x172DE760>>
TRACE: 'ascii' codec can't encode character u'\u0439' in position 35: ordinal not in range(128)
Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "RoMEventManager", line 422, in onGameUpdate
File "OOSLogger", line 23, in doGameUpdate
File "OOSLogger", line 122, in writeLog
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0439' in position 35: ordinal not in range(128)
Message #30 received from player -1 for turn 1 - Updating Global Define (null), New Values are Int 1689081816, Float 0.000000, String (null)
-1 ? it need to be 2 ? 1 is ai.....
but i have english game...
and game gave me OOS and error
TRACE: Error in gameUpdate event handler <bound method RoMEventManager.onGameUpdate of <RoMEventManager.RoMEventManager instance at 0x172DE760>>
TRACE: 'ascii' codec can't encode character u'\u0439' in position 35: ordinal not in range(128)
Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "RoMEventManager", line 422, in onGameUpdate
File "OOSLogger", line 23, in doGameUpdate
File "OOSLogger", line 122, in writeLog
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0439' in position 35: ordinal not in range(128)
Message #30 received from player -1 for turn 1 - Updating Global Define (null), New Values are Int 1689081816, Float 0.000000, String (null)
-1 ? it need to be 2 ? 1 is ai.....
but i have english game...
That message can't be sent by the DLL code. Either Int or Float are -1 in all cases. So there is something fundamentally wrong about the game state.
Besides, I think not everything in the C2C DLL is serialized into a savegame that would be required to sync the game state between a host already in the game (Pitboss) and a client joining.
I have a theory about how great commander exp may differ and cause OOS's to occur.
When almost anything about a unit's properties has to be determined, it will make a call to getCommander(), because the presence of a usable commander can change most queried properties. If it finds a commander to use it will cache that commander's id and use it again (assuming it's still alive and still has command points and so on) on the next call (for the same unit).
For the AI this is fine, since the AI will make the same requests and so generate the same caching sequence on all machines.
However, suppose the human player has 2 great commanders nearby and does the following:
1) Check the attack odds for a unit against an enemy (right click and hold) but then NOT execute the attack. The determining of the odds will have cached a commander against the unit that didn't attack.
2) Move the unit to a nearby tile and then attack with it from there, which happens to be nearer the OTHER great commander (both still within command range though). This will continue to use the original GC, because its still valid and cached for that unit. However, on another machine when the final move and attack orders are pushed, the aborted odds-determination is never run, so the first commander is not cached. Thus the unit performs its search for best commander on the actual attack, when it is nearer the OTHER GC, so it picks that one instead.
There may be simpler scenarios, where an unsynchronised action (the odds check in this case) causes a commander to be cached, that also result in differences in outcome.
Anyway, I have modified the code to disable the caching for human units. We'll see if this helps. This change will be pushed to SVN later today.
When almost anything about a unit's properties has to be determined, it will make a call to getCommander(), because the presence of a usable commander can change most queried properties. If it finds a commander to use it will cache that commander's id and use it again (assuming it's still alive and still has command points and so on) on the next call (for the same unit).
For the AI this is fine, since the AI will make the same requests and so generate the same caching sequence on all machines.
However, suppose the human player has 2 great commanders nearby and does the following:
1) Check the attack odds for a unit against an enemy (right click and hold) but then NOT execute the attack. The determining of the odds will have cached a commander against the unit that didn't attack.
2) Move the unit to a nearby tile and then attack with it from there, which happens to be nearer the OTHER great commander (both still within command range though). This will continue to use the original GC, because its still valid and cached for that unit. However, on another machine when the final move and attack orders are pushed, the aborted odds-determination is never run, so the first commander is not cached. Thus the unit performs its search for best commander on the actual attack, when it is nearer the OTHER GC, so it picks that one instead.
There may be simpler scenarios, where an unsynchronised action (the odds check in this case) causes a commander to be cached, that also result in differences in outcome.
Anyway, I have modified the code to disable the caching for human units. We'll see if this helps. This change will be pushed to SVN later today.
That sounds correct and hopefully not caching that will not be a too large performance hit for humans.
All right we were able to put a further few hours into the game... finally in the AD time period!
The autohunt/explore/go-to is generally fixed with an exception. When a unit is promoted to +1 movement AND uses that movement on the same turn the game will still OOS. This was further replicated with a spy who was given the +1 movement, and a ship. Its somewhat rare, I would say its not too game breaking at this point in our game but if it were the early days again and we had units getting 1,000's of xp it *could* be a minor issue.
A possible side effect of the modification - ships not under manual control are essentially useless. On explore or hunt, they rarely leave boarders. It may have been this way prior to the patching, dunno, didn't have a strong navy.
There is a definite lag to every turn now, but honestly, I much prefer a lag filled 5 to 60 seconds at the beginning of a turn rather than having to reload the game constantly because of the sync issues.
We also had one further unknown OOS. Im currently on military duty so wont be able to upload that for a short while
Thanks for the huge strides in multiplayer compatibility so far, its actually becoming quite enjoyable.
The autohunt/explore/go-to is generally fixed with an exception. When a unit is promoted to +1 movement AND uses that movement on the same turn the game will still OOS. This was further replicated with a spy who was given the +1 movement, and a ship. Its somewhat rare, I would say its not too game breaking at this point in our game but if it were the early days again and we had units getting 1,000's of xp it *could* be a minor issue.
A possible side effect of the modification - ships not under manual control are essentially useless. On explore or hunt, they rarely leave boarders. It may have been this way prior to the patching, dunno, didn't have a strong navy.
There is a definite lag to every turn now, but honestly, I much prefer a lag filled 5 to 60 seconds at the beginning of a turn rather than having to reload the game constantly because of the sync issues.
We also had one further unknown OOS. Im currently on military duty so wont be able to upload that for a short while
Thanks for the huge strides in multiplayer compatibility so far, its actually becoming quite enjoyable.
They should not. If they do, then that is something to fix.
Nope, not gotten around to it yet. Lots of things on my list still and little time.
I'm not sure if I should really post this here, or create a new Multiplayer Issues thread, but we've encountered several OOS errors today.
For some reason though only one of them seems to have creates an OOS log on both Computers- and the only Random Logger log today was saved half an hour later!?
I've attached the matching OOS Logs, as well as that Random Logger Log (though I doubt this latter one will do you much good since it seems to have saved so much later- is there anything we should do to ensure that this matches up properly?).
Also, I'm not sure if this is cause or just co-incidence, but we didn't have any problems playing the game for hours when we started it, but within half an hour of loading up the save tonight it OOS'd. And then every time we reloaded to continue it seemed to OOS sooner and sooner.
I don't know if this is just a co-incidence because we're at some point in the game (mid-classical) which is just prone to OOS, or if there's something in the save/loading process which is actually helping to generate these OOSs. Just thought I'd raise the point, because I've seen this behaviour in several of our games now, and I don't know how random numbers etc are re-generated/loaded on a reload.
Oh, and I forgot to mention- this is on SVN Revision 1778, with two custom civs added in. Custom Civ XML is in the spoilers tag if you wanted it.
- Micael
For some reason though only one of them seems to have creates an OOS log on both Computers- and the only Random Logger log today was saved half an hour later!?
I've attached the matching OOS Logs, as well as that Random Logger Log (though I doubt this latter one will do you much good since it seems to have saved so much later- is there anything we should do to ensure that this matches up properly?).
Also, I'm not sure if this is cause or just co-incidence, but we didn't have any problems playing the game for hours when we started it, but within half an hour of loading up the save tonight it OOS'd. And then every time we reloaded to continue it seemed to OOS sooner and sooner.
I don't know if this is just a co-incidence because we're at some point in the game (mid-classical) which is just prone to OOS, or if there's something in the save/loading process which is actually helping to generate these OOSs. Just thought I'd raise the point, because I've seen this behaviour in several of our games now, and I don't know how random numbers etc are re-generated/loaded on a reload.
Oh, and I forgot to mention- this is on SVN Revision 1778, with two custom civs added in. Custom Civ XML is in the spoilers tag if you wanted it.
Spoiler :
- Micael
If you do get an OOS you HAVE to go back at least one turn to before the OOS happened, not the same turn. Otherwise the OOS reason could stay and become worse by every turn passing.
I know, doesn't make much sense but seems to be valid. I'm sure someone will refute it though. *grin*
Cheers
I know, doesn't make much sense but seems to be valid. I'm sure someone will refute it though. *grin*
Cheers
Similar threads
