Opened 9 years ago

Closed 9 years ago

#3151 closed defect (fixed)

OOS on rejoin - different visibilities for structures after resign

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

Description

We played the a18 version, fpre rejoined and we got this oos error. Both oos_dump's and a commands.txt are attached.

(1) When comparing the files, we can see that there is visibilities: 128 instead of visibilities: 144 in line 86762 or 1365789 (i.e. in the beginning / at 6% of the file)

(2) The other differences are missing entities near the end of the dump in line 1341163 or 1365789 (i.e. at 98% of the file), probably a result of (1). Im not 100% sure if it is only missing entities, or if there are actually entities that differ, since the diff tool sometimes shows differences of different entities as if they occured in the same entity...

Attachments (2)

oos_dump_commands.txt.7z (698.1 KB ) - added by elexis 9 years ago.
oos_dumps and my commands.txt
t3151_oos_dump_commands_txt_reproduce.7z (80.1 KB ) - added by elexis 9 years ago.
All commands.txt and oos_dump files of host (player 1) and rejoined client (player 2) described above.

Download all attachments as: .zip

Change History (8)

by elexis, 9 years ago

Attachment: oos_dump_commands.txt.7z added

oos_dumps and my commands.txt

comment:1 by elexis, 9 years ago

Maybe related or identical bug as in #3107.

comment:2 by Itms, 9 years ago

Owner: set to Itms
Summary: [OOS on rejoin] one-line difference in the visibilitiesOOS on rejoin - one-line difference in the visibilities

I'm on it!

comment:3 by sanderd17, 9 years ago

You could try with actually serializing the range in CcmpVision.

Currently, the vision range is recalculated on the MT_Deserialised message, which happens after deserialisation itself. While the RangeManager executes the "ResetDerivedData" function on the deserialisation itself. So I have a feeling that the vision range update might come a bit too slow.

comment:4 by historic_bruno, 9 years ago

Priority: Should HaveRelease Blocker

comment:5 by elexis, 9 years ago

Summary: OOS on rejoin - one-line difference in the visibilitiesOOS on rejoin - different visibilities for structures after resign

In this case, the entity is not a foundation but an actual structure:

    id: 5096
    template: "structures/athen_dock"

The visibilities mask values 128 and 144 mean: 128 -> 10 00 00 00 -> entity is visible for player 4, invisible for player 3 (and invisible to others) 144 -> 10 01 00 00 -> entity is visible for player 4, fogged for player 3 (and invisible to others)

Notice the player has resigned, therefore he can see all entities (call to SetLosRevealAll in OnPlayerDefeated).

Sounds like if one resigns or reveals the map, the mirages should be cleaned up.


I tried to reproduce the issue. I built a dock and then moved my unit back, so that the dock is fogged. Then I resigned and rejoined with player 2. The result was an out of sync error with the following diff:

--- oos_dump_1432867119_2130.txt	2015-05-29 04:38:39.876503000 +0200
+++ oos_dump_1432867119_2398.txt	2015-05-29 04:38:39.892503000 +0200
@@ -5958,31 +5958,37 @@
   },
   "techModifications": {
     "0": {
       "gaia/fauna_chicken": {},
       "gaia/flora_bush_berry": {},
       "gaia/geology_metal_temperate_slabs": {},
       "gaia/geology_stonemine_temperate_quarry": {},
       "gaia/flora_tree_oak": {},
       "gaia/flora_tree_euro_beech": {},
       "gaia/geology_stone_temperate": {},
       "gaia/fauna_deer": {},
       "gaia/fauna_goat": {},
       "gaia/fauna_fish": {},
       "gaia/flora_tree_poplar": {},
       "gaia/flora_tree_apple": {},
-      "resource|gaia/fauna_chicken": {}
+      "resource|gaia/fauna_chicken": {},
+      "structures/gaul_civil_centre": {},
+      "units/gaul_support_female_citizen": {},
+      "units/gaul_infantry_spearman_b": {},
+      "units/gaul_infantry_javelinist_b": {},
+      "units/gaul_cavalry_javelinist_b": {},
+      "structures/gaul_dock": {}
     },
     "1": {
       "campaigns/campaign_city_minor_test": {},
       "campaigns/campaign_city_test": {},
       "campaigns/campaign_religious_test": {},
       "other/bench": {},
       "other/bridge_hele": {},
       "other/bridge_wooden": {},
       "other/cart_tophet": {},
       "other/celt_hut": {},
       "other/celt_longhouse": {},
       "other/column_doric": {},
       "other/column_doric_fallen": {},
       "other/column_doric_fallen_b": {},
       "other/fence_long": {},
@@ -14694,9 +14700,9 @@
     key: 228
     x: 341.33333
     z: 102.4
     vision: 90
-    visibilities: 38
+    visibilities: 34
     size: 18
     retain in fog: 1
     owner: 0
     in world: 1
@@ -18094,9 +18100,9 @@
     key: 618
     x: 468.12397
     z: 209.72245
     vision: 40
-    visibilities: 38
+    visibilities: 34
     size: 13
     retain in fog: 1
     owner: 0
     in world: 1

Those two entities with changed visibilities are

id: 228
template: "structures/gaul_civil_centre"

id: 618
template: "structures/gaul_dock"

A visibilities mask value of 34 (=10 00 10) means that it is visible to player 1 and 3, but it is fogged for player 2. 38 (=10 01 10) means that it is visible to player 1 and 3 as well, but invisible to (rejoined) player 2.

Player 3 was a bot, therefore it can see all entities. Player 2 is an ally of player 1 and the CC and the dock are fogged after the defeat of player 1 for him.

Not sure what the techModifications diff is about.

by elexis, 9 years ago

All commands.txt and oos_dump files of host (player 1) and rejoined client (player 2) described above.

comment:6 by elexis, 9 years ago

Resolution: fixed
Status: newclosed

This issue was also fixed by r16857.

Before #2055 / r16795, you could reproduce it this way:

-start 2v2 match -resign with player 1 -rejoin with player 2 (which is an ally of player 1) -oos

After that commit, you had to do it this way:

-start 2v2 match -build market with player 2 and research vision tech -resign with player 1 -rejoin with player 2 (which is an ally of player 1) -oos

The latter recipe worked until r16856. Since r16857 I can't reproduce it anymore.

Note: See TracTickets for help on using tickets.