Opened 9 years ago

Closed 9 years ago

#3075 closed defect (fixed)

Out of sync on rejoin

Reported by: elexis Owned by: leper
Priority: Release Blocker Milestone: Alpha 18
Component: Core engine Keywords:
Cc: Patch:

Description

This 1v1 was played on 24.02 with revision 16382. First out of sync happened after one player was dropped. Second one happened when I (spectator) dropped. I attached the oos_dumps of the two players. These dumps are very similar, the difference is very little. One should be able to find the cause I hope.

(My oos dum was created on the second oos, so it is completely different and cannot be compared to the two oos_dumps).

On request I can hand in commands.txt for all three clients and other logfiles for one player & me (spectator).

Attachments (5)

oos_dump_player1+2.7z (543.2 KB ) - added by elexis 9 years ago.
The two similar oos_dump files of both players.
oos_dump_player1+2_unix.7z (283.8 KB ) - added by elexis 9 years ago.
One client uses ubuntu, one uses windows, thats why the logs have different file ending formats. Both in unix format with this upload.
diff.7z (9.0 KB ) - added by elexis 9 years ago.
The diff of those 2 oos_dumps. The first difference occures in the RangeManager
commands.txt.7z (234.6 KB ) - added by elexis 9 years ago.
Commands.txt for all three clients
useless_oos_dump_elexis_from_different_rejoin.7z (305.4 KB ) - added by elexis 9 years ago.
That is my oos dump from that game, which is indeed useless since it is completely different (starting with the random number generator state in the first line), i.e. was made on the second rejoin. (sanderd17 was right on irc on 24.02.) The two dumps from ffm and gussebb uploaded above however seem to be useful.

Download all attachments as: .zip

Change History (11)

by elexis, 9 years ago

Attachment: oos_dump_player1+2.7z added

The two similar oos_dump files of both players.

by elexis, 9 years ago

Attachment: oos_dump_player1+2_unix.7z added

One client uses ubuntu, one uses windows, thats why the logs have different file ending formats. Both in unix format with this upload.

by elexis, 9 years ago

Attachment: diff.7z added

The diff of those 2 oos_dumps. The first difference occures in the RangeManager

by elexis, 9 years ago

Attachment: commands.txt.7z added

Commands.txt for all three clients

comment:1 by elexis, 9 years ago

Gussebb was the host of this session and played as gauls. His commands.txt contains all commands (0-7098).

ffm played as mauryan and was the first to drop & rejoin at turn 5198. I dropped at turn 6903 and rejoined at turn 6940.

My oos_dump is probably from this turn, while the other two are from turn 5198, i.e. only those two can be compared.

F's commands.txt for the turns 0 to 5198 is missing.

Last edited 9 years ago by elexis (previous) (diff)

comment:2 by Lionkanzen, 9 years ago

Is this a knew issue? I think is reported before as OoS

comment:3 by elexis, 9 years ago

It is the first time i have published those logs. Notice the match was played 3 days ago. Maybe you can find the same error in another thread. If so - what is the error? :D

comment:4 by elexis, 9 years ago

I just wanted to note that those two oos_dumps are made in the same turn with high probability. They share the same first 14686 lines, i.e. 97,83% of the dump is identical. I assume that most of the diff is just a result of the first difference.

(The oos_dump that was 100% different from those two above was mine (spectator), since it was created when I rejoined. That was the one i talked about on IRC on 24.02. and is not to confuse with those two oos_dumps.)

I'll try to simulate that stuff...

by elexis, 9 years ago

That is my oos dump from that game, which is indeed useless since it is completely different (starting with the random number generator state in the first line), i.e. was made on the second rejoin. (sanderd17 was right on irc on 24.02.) The two dumps from ffm and gussebb uploaded above however seem to be useful.

comment:5 by leper, 9 years ago

elexis suspected the archer tech (Mauryans; barracks; town phase) to be the cause and was able to reproduce this earlier.

I do now have a small testcase and am able to reproduce it.

comment:6 by leper, 9 years ago

Owner: set to leper
Resolution: fixed
Status: newclosed

In 16401:

Do not send VisionRangeChanged messages when deserializing. Fixes #3075.

Note: See TracTickets for help on using tickets.