Map Desync Issues

[YeetYa]

Greetings everyone,
I'm brand new to this site and would love to get some help. Ever since the recent Warcraft 3 patches I know a lot of maps have had desync problems, even with restarting the game to clear the cache. I'm currently trying to get the Eras Zombie Invasion 24p map to work in particular, but have had a few issues that need to be addressed. I'm not 100% sure what is causing the desync in the first place so I've been trying to remove certain assets and testing it in order to check what is actually causing the desync. Testing for desync is awfully hard, we have to fill nearly the entire 24 players in order to test if it actually desyncs since anything less than half doesn't show if it will desync. Would really appreciate if anyone could help me out with either of these 1. How to test desync without having 24 people join the game and 2. What exactly is causing the desync and any help on how to fix it would be appreciated. Thanks!

 

[Pyrogasm]

since anything less than half doesn't show if it will desync.

This is probably not true; it's not that it's not happening, it's that with fewer people in the game the desync is more likely to involve at least one player slot that's empty. If it does only happen with >12 players, that's a massive clue as to where you should be looking for the source of desyncs. It would be something different between one of the last player slots and the rest of the player slots.

To quickly look for possible error spots, open your map with an mpq/casc editor and extract the war3map.j file. That's the entire map script for the triggers. Search through it for instances of GetLocalPlayer(), as that is almost guaranteed to be involved in the desync. (or some other function that calls it like SmartCameraPanB)

 

[YeetYa]

This is probably not true; it's not that it's not happening, it's that with fewer people in the game the desync is more likely to involve at least one player slot that's empty. If it does only happen with >12 players, that's a massive clue as to where you should be looking for the source of desyncs. It would be something different between one of the last player slots and the rest of the player slots.

To quickly look for possible error spots, open your map with an mpq/casc editor and extract the war3map.j file. That's the entire map script for the triggers. Search through it for instances of GetLocalPlayer(), as that is almost guaranteed to be involved in the desync. (or some other function that calls it like SmartCameraPanB)

Pyrogasm,
Thanks I really appreciate your reply, unfortunately knowing which player spots are empty is difficult, the map I'm working on every color represents a different nation and various slots are filled and unfilled based on the players choice on which country they want to play and not filled in direct order. I extracted the war3map.j file and searched for instances of GetLocalPlayer() and SmartCameraPanB and I could not find any of them. You said that there were more functions that call GetLocalPlayer, is there a list somewhere I can find that? Thanks!

 

[Pyrogasm]

Anything in here that shows up when you search for it: JASS Manual: API Browser - Blizzard.j

 

[YeetYa]

Anything in here that shows up when you search for it: JASS Manual: API Browser - Blizzard.j

Thanks for the information this is extremely helpful. I went through and found every function that calls it in my code and found: SetCameraFieldForPlayer, DisplayTextToForce, and DisplayTimedTextToForce. Do I need to remove the function completely or is there a way to use the function without the issues of desync?

Edit - Got a full house running, we had 16 desyncs and I have removed every single reference of the function GetLocalPlayer()... any help?

 

[Pyrogasm]

So the GLP blocks were probably there FOR a reason, they just might not have been treated with proper caution and could have contributed to desync-ing. Most of the Blizzard uses of GLP are fine, it's really a question of whether or not some asynchronous data is made.

If you really did remove every instance of it from your map and disabled all of the blizz functions that use it... then I really have no idea what to suggest you look for next. Desync happen because something is asynchronous and the only way I know of to do that is with GLP. Perhaps some of the Preload natives can deal with asynchronous data, but I'm not familiar with those.

 

[YeetYa]

So the GLP blocks were probably there FOR a reason, they just might not have been treated with proper caution and could have contributed to desync-ing. Most of the Blizzard uses of GLP are fine, it's really a question of whether or not some asynchronous data is made.

Yeah, I know most of the instances of the function were used correctly I just wanted to check if the source of the desync was those functions. I have heard that other causes of desync could be due to the custom models or animations, is there any merit behind this? Also I have heard about memory leaks, but I assume that would not cause desync, but a crash.

 

[Pyrogasm]

I have heard that other causes of desync could be due to the custom models or animations, is there any merit behind this?

I have no knowledge one way or the other about this.

Also I have heard about memory leaks, but I assume that would not cause desync, but a crash.

Correct. I suppose it's possible that the map lagging significantly for one player but not another (first of all, how would that happen besides a computer specs thing? idk) could make some events fire asynchronously or cause a wait to progress differently... but I have never specifically heard of that happening. I'm just guessing based on my intuition.

 

[coolyoshi1]

If i remember correctly a long time ago someone mentioned they tested desyncs caused by terrain deformations. The terrain deformations only desynced when alot of instances of terrain deformations occur at same time. I'm not sure but maybe this could be a case that backs up your theory that lag can cause certain events to be asynchronous

 

[troylowyee]

Does your map have damage detection or any other systems? Try making a copy of the game and deleting certain systems in your game. I had a map that desyncs also it used to work in the older versions. I removed had to remove the GetLocalPlayer() and the damage detection for it to work properly. Maybe I have been using it incorrectly.

I noticed that for both of my maps, i had a dummy with like the attack type NONE but the attack enabled is for attack one, it caused the desync, something along that line, it was many months ago and it was in the 1.30 patch.

 

[Daethz]

Found this thread. My map is also having a ton of desync issues.
How can i convert my GUI code into jass so i can look through for getlocalplayer, is there a app in the tools in this site?
No bug has ever eluded me like this before.

 

[Pyrogasm]

Open the map with an MPQ or CASC viewer application and extract the war3map.j file. That is the compiled JASS code that the map runs.

 

[Rigborn]

WC3 Data don't know if it's still working but all you have to do it load your map then it does the job.

You will probably see a lot of bj functions since your map is mostly GUI to check those bjs here's the link: JASS Manual: API Browser - Blizzard.j

 

[Daethz]

Zero GetLocalPlayer()'s in 51 thousand lines
Now im concerned, wtf is causing my desyncs

 

[maddeem]

From reading around, it looks like polled waits also cause desynchronization.

 

[YeetYa]

Zero GetLocalPlayer()'s in 51 thousand lines
Now im concerned, wtf is causing my desyncs

Sorry for the very late response, but I have managed to fix my desync issues. I too removed the very instance of GetLocalPlayer() and was so confused what was going on. I reset the game interface and gameplay constants and this fixed my game. I don't have the time to narrow down what exactly is causing it, but resetting these two things are worth a try.

 

[Daethz]

Sorry for the very late response, but I have managed to fix my desync issues. I too removed the very instance of GetLocalPlayer() and was so confused what was going on. I reset the game interface and gameplay constants and this fixed my game. I don't have the time to narrow down what exactly is causing it, but resetting these two things are worth a try.

Yeah I have seen another thread saying that causes desyncs.
I have none in my game though

And I can't remove the Wait timers from my game, too many things rely on them, replacing all waits with timers would take years and simply wouldn't even be worth trying.
Not to mention some things literally wouldn't work with them.

I think the removal of my single "Wait Game-Time" improved the games stability a ton, but people are still having desync issues and apparently crashing issues with the new slots.

I see blizzard is fixing desyncs on a map by map basis on their latest PTR patch notes, so its possible some of it may be their fault.

 

[maddeem]

Yeah I have seen another thread saying that causes desyncs.
I have none in my game though

And I can't remove the Wait timers from my game, too many things rely on them, replacing all waits with timers would take years and simply wouldn't even be worth trying.
Not to mention some things literally wouldn't work with them.

I think the removal of my single "Wait Game-Time" improved the games stability a ton, but people are still having desync issues and apparently crashing issues with the new slots.

I see blizzard is fixing desyncs on a map by map basis on their latest PTR patch notes, so its possible some of it may be their fault.

It is 100% their fault. They introduced desyncs that simply did not exist before. However, Daethz you can remove the in-game waits by replacing them with the other variant (local waits [TriggerSleepAction]).

Polled waits are terrible when it comes to efficiency as well.

function PolledWait takes real duration returns nothing
    local timer t
    local real  timeRemaining

    if (duration > 0) then
        set t = CreateTimer()
        call TimerStart(t, duration, false, null)
        loop
            set timeRemaining = TimerGetRemaining(t)
            exitwhen timeRemaining <= 0

           // If we have a bit of time left, skip past 10% of the remaining
           // duration instead of checking every interval, to minimize the
           // polling on long waits.
            if (timeRemaining > bj_POLLED_WAIT_SKIP_THRESHOLD) then
                call TriggerSleepAction(0.1 * timeRemaining)
            else
                call TriggerSleepAction(bj_POLLED_WAIT_INTERVAL)
            endif
        endloop
        call DestroyTimer(t)
    endif
endfunction

So this is the actual code behind the PolledWait function. The accuracy for polled waits can be off anywhere from 0.1 to values exceeding 10 seconds on a wait of 100 seconds. If you do a PolledWait of 0 seconds, it will not do any TriggerSleepAction. My theory as to why this desyncs is that it evaluates the timer value every 0.1 seconds (On waits over 2 seconds) with every player. If a player has say over 100ms latency (0.1 seconds) their timer value will be different from everyone else. The game registers that as a desyncs and quickly boots them from the session. I also believe the battle.net latency limit for Warcraft III servers is currently 300ms. So you may really only run into problems with players desyncing at or above 300 ms.

Is this actually what happens? Who knows, but we can't really tell without looking at the source code as far as I'm concerned.

Now TriggerSleepAction is really no better when it comes to accuracy, however, in theory cannot cause desyncs as the evaluations it does are local.

Edit: Polled waits leak the timer handle.

Edit 2: I know you said it would take years to implement timers, but it really shouldn't. Sure it will take some time and tutorial reading, but in the end it will save you a big headache of your game not working at all in multiplayer. It will also make your game far more stable and precise, which is a big plus for a competitive multiplayer game.