Lua GUI timers always desync (minimal repro)

Affected versions: at least since 1.32.10 - current PTR 2.0.3.23025

Reproduction map (I don’t think I can attach files here):
0. Trigger Editor

  1. Variable “aTimer” of type Timer
  2. New Trigger
  3. Events: one of {Map initialization, Elapsed game time is 0.00, or 5.00 seconds} - doesn’t matter which one
  4. Actions: Countdown Timer - Start a “aTimer” as Repeating timer that will expire in 0.01 seconds
  5. Change map to Lua mode: Scenario - Map Options

That’s all. Make the map for 2 players and test in LAN lobby. Just wait and it will desync within 15-20 seconds depending on event you chose.

Lua: When I had been testing it in 1.32.10, this had roughly a 50% chance to desync, iirc. Today it’s 100% across like 6 runs. It may affect modified melee maps set to use Lua mode.

Jass: Works fine.

PS: possibly related DS Bug Reports - Lua GUI Timers Cause Desync

Hello,

Can you please provide a map and exact steps to reproduce this?

Our team has tried and cannot figure out how to reproduce it.

Thank you!

Here’s the link to download the map (it’s in the folder): https://github.com/Luashine/wc3-test-maps/tree/master/EarlyTimerDesyncsLua (commit 6388713)

Sorry about wasting time on this back-and-forth, I was too afraid of posting external links in my first post ^_^

Again, absolutely positive about reproduction in current Retail 2.0.3.22988 and PTR 2.0.3.23052

During further extensive testing, I determined it may be related to
my other bug report
with regards to GC: Desync due to Lua objects and GC (init phase) except the current one is reachable from GUI Trigger Editor.

Why? Look at this code, generated by WE for this map (called via main()):

udg_aTimer = nil
gg_trg_Melee_Initialization = nil
gg_trg_InitTriggerMAPINITDesyncs = nil
gg_trg_InitTriggerDelay0Desyncs = nil
gg_trg_InitTriggerDelay5Desyncs = nil
function InitGlobals()
    udg_aTimer = CreateTimer() -- required to desync at 0:15
end

function Trig_InitTriggerMAPINITDesyncs_Actions()
    StartTimerBJ(udg_aTimer, true, 0.01) -- required to desync at 0:15
end

function InitTrig_InitTriggerMAPINITDesyncs()
    gg_trg_InitTriggerMAPINITDesyncs = CreateTrigger()
    TriggerAddAction(gg_trg_InitTriggerMAPINITDesyncs, Trig_InitTriggerMAPINITDesyncs_Actions)
end

function Trig_Melee_Initialization_Actions()
    MeleeStartingVisibility()
    MeleeStartingHeroLimit()
    MeleeGrantHeroItems()
    MeleeStartingResources()
    MeleeClearExcessUnits()
    MeleeStartingUnits()
    MeleeStartingAI() -- this and the rest were not tested
    MeleeInitVictoryDefeat() -- required to desync at 0:15
end

It turns out, the desync only happens if:

  • my timer is created and started
  • MeleeInitVictoryDefeat() is enabled in GUI. If you look at this blizzard.j function, it creates a lot of objects:
    • creates many triggers that overwrite local variables (thus game objects going out of scope → potential GC)
    • timer dialogs
    • creates and starts a 2.0s timer at the end

Note: the desync immediately triggers the victory condition for host.

My hypotheses are:

  • either the first game turn is not properly synced (my GUI timer is 0.01s periodic, game turns are 0.1s(?))
  • or it’s the GC

Tested in “self-LAN” on my PC with 2 clients: multiplayer, two players.

Thank you. I, we, appreciate the renewed care a lot.


UPD: I asked someone else to test, GrapesOfWath said he did not have a desync. I tried again, downloading my map from the same link: desyncs for me 100%.

Tested: enUS and ruRU locales. Allow Local Files = 0. Windows 10: winver.exe Version 22H2 (OS Build 19045.6093)

I will ask more people to test this and the other test map too (root object GC test case).

1 Like

Hello.

Can you reproduce this in multiplayer, or is it a LAN-only issue?

  1. I could NOT reproduce this in Battlenet on either map: 0/2 per map with other players
  2. Other people DID reproduce it in LAN: 3/4 (including me, only Grapes said no repro on this map)

Both Strelock and Purge below came from my testing instructions for LAN:

Strelock says: Both maps desync first try
OS: Microsoft Windows 11 Pro, Version 10.0.26100 Build 26100
Game Language: English
Game version: 2.0.3.22988

PurgeandFire: Both maps desynced for me on the first try as well, exactly as you described. :thumbs_up: I ran the test on one machine with two wc3 clients via LAN.
OS: Microsoft Windows 10, Version 22H2 Build 19045.6216
Game Language: English (en_US)
Game Version: 2.0.3.22988 (release as of writing)

Myself: always desyncs in LAN, 2 clients on one PC
OS: Windows 10 22H2 (19045.6218)
Language: ruRU or enUS
Game version: 2.0.3.22988 & 2.0.3.23051 (previous PTR)

PS: I would like to add, this discrepancy makes local testing for desyncs impossible. Which is the usual recommendation for mapmakers when they introduce new stuff. It took me like 30min to find 3 people to test it with :confused: Cheers!

1 Like

The desync you’re describing here is, to my knowledge, caused by a timer being created by blizzard.lua in the Lua root and stored to bj_lastStartedTimer. StartTimerBJ overwrites that timer, causing it to be garbage collected. Garbage collection can cause desyncs for objects created in the Lua root.

1 Like