This repository has been archived by the owner on Apr 17, 2022. It is now read-only.
desynch when transferring units #4785
Labels
Milestone
Comments
|
andrvaut uploaded file all log |
|
Berserk Cyborg changed blocking which not transferred by tractive |
|
Berserk Cyborg changed blockedby which not transferred by tractive |
|
Berserk Cyborg changed priority from |
|
Cyp edited the issue description |
|
Cyp changed title from |
|
Cyp commented Seems that the clients disagree on whether structure 806 and structure 815 completed production of a droid each in tick 2345 or tick 2346. At first glance it's not obviously related to transferring units. |
|
Prot commented Cyp, this is only at first glance, I have made some observations, DESYNC causes several reasons.
|
|
Cyp <cyp@...> committed [99222] In Warzone2100/warzone2100@99222df: |
|
Cyp commented Couldn't reproduce easily. To try to narrow it down slightly, would it be possible to reproduce with the above version (or later) and attach the logs again? All clients get the logs from each other automatically (the p# in the filename says which client it's from), so the logs from one computer should be enough. |
|
Cyp commented From https://forums.wz2100.net/viewtopic.php?f=6&t=14861&p=142661 — Thanks for the update — if I'm seeing it right, the CheckHaltOnMaxUnitsReached function sometimes returns 0 on client A but 1 on client B, at the moment when client A has 150 units and gives some to another player. Possible to reproduce now, the trick is to be at the unit limit and building units, before transferring. |
|
Cyp <cyp@...> changed status from |
|
Cyp <cyp@...> changed owner from `` to |
|
Cyp <cyp@...> changed resolution from `` to |
|
Cyp <cyp@...> committed [1117874] In Warzone2100/warzone2100@1117874: |
|
pastdue changed status from |
|
pastdue changed resolution from |
|
pastdue commented From: http://forums.wz2100.net/viewtopic.php?f=6&t=14861
|
|
Cyp commented At first glance, looks like it's a different bug, even if the trigger and symptoms are the same. |
|
Cyp commented Couldn't reproduce the last bug easily. Added some more debug to the logs in 644ffe39672b9f2637bccabd8cd77f8a45340694, not sure if it can help, but maybe new logs from that version (or later) might help narrow it down slightly. |
|
andrvaut uploaded file |
|
andrvaut uploaded file |
|
andrvaut commented In the last master, the desink began to appear much less frequently. |
|
Cyp commented Thanks — in most of the new desynchs, I think they were due to gtnz using version 1117874 of the game. It's important for everyone to use the exact same version. One real desync in there (while processing a message to transfer droids to another player), between players with the same version, though: |
|
andrvaut commented Yes, this is our mistake. We noticed this after all the tests. |
|
Cyp commented The thing is that if one client doesn't have the enhanced synch debug but the other does, then the clients generate different synch logs, and therefore believe they are out of synch with each other, even when they aren't.Not sure why the bot didn't say anything — oh, oops, wrong ticket number, that's why…, but this might be fixed in b0cc06955d1835c299339a4393d481a41b4e4610 — please reopen if not. |
|
Cyp changed status from |
|
Cyp changed resolution from `` to |
|
Cyp commented Oh, oops again, can't reopen if not marked as (hopefully) fixed. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
resolution_fixedtype_bug| by andrvautOften after the transfer of units, desynchs occur.
Usually it disappears within 1-2 seconds, but sometimes it leads to a global desynchronization.
Issue migrated from trac:4785 at 2022-04-16 13:06:10 -0700
The text was updated successfully, but these errors were encountered: