[Crash] Desynchronization

[trall12]

Hello Dear mappers, I came to you today with the hope that at least you will be able to help me resolve my problem,in the map desynchronisation happens, it happens not always and not at the same time,I don't know what the reason,in the gloom I thought that the problems in the units and resil to do them all again on non-standard basis, that would not spesialis with standard but in the end the result it gave desynchronization remained,he only Hope of success to you my dear mappmakers
help please,attach map for inspectionView attachment Foots Action.w3x

 

[jonhysone]

Please tell me when it desync, does it desync at random times?

 

[trall12]

Please tell me when it desync, does it desync at random times?

Yes at random time, usualy at 15-25 min of game

 

[Dr Super Good]

Do note that WC3 seems to have a natural level of desynchronization at the moment. I am seeing people being dropped for being out of sync quite randomly in bot games at the moment. I am unsure if it is due to variances in hardware, third party modifications, previous maps they played bleeding data across or even buggy robot host servers.

In any case avoid GetLocalPlayer unless you know what you are doing and even then it should only be for visual effects. Avoid GetLocationZ for anything but visual effects as the results are not deterministic so cannot alter game play. Avoid actions that generate excessive net traffic as I would not be surprised if host servers start to mess up and skip relaying some of the packets (instant out of sync) however this is purely speculation. Avoid excessive leaks, since although they should not cause people to lose synchronization (as all leaks occurrences are synchronized) it might be the internal state of WC3 deals with large numbers of object differently after one or more sessions were played without restarting.

 

[jonhysone]

^ Exactly,

I used to be a stupid mapper, I was using huge leaking triggers , calculating many things , which caused a desync since some computers can't handle that huge computing and calculating.

Just don't do huge calculating upon a very short period (0.03sec for example)... If your problem isn't solved after some time, please post a message (visitor or private) so I revise your map when I have time. Currently it all depends on you or more people to help.

 

[Crystalknoct]

I have this same problem however my map desyncs at map initialization and usually splits a full game in half lol. Makes me prefer gameranger most days for warcraft 3 tbh never have these issues.

 

[Zwiebelchen]

I have this same problem however my map desyncs at map initialization and usually splits a full game in half lol. Makes me prefer gameranger most days for warcraft 3 tbh never have these issues.

desync at map init can have multiple reasons; for example, getting the PlayerSlotState at map init.
All of those desyncs are usually avoidable, except the one that is caused by widgetizer.

Unfortunately, there is no way to convince mappers not to use widgetizer. Scrubbing of 3 seconds of load time seems more important than ensuring that people don't have to restart WC3 every time they want to play a different map afterwards.
Because fuck those, right?

@OP:
A desync that happens not at map init but after 15-25 minutes at seemingly random times is 100% caused by the map script. Contrary to popular belief Bnet sessions are extremely stable if the map code is good. You don't just randomly desync because the game says so (disconnect is a different story, but those are caused by the client, not the game).
Examine which script is running at that time and post it here for us to debug.

Do note that WC3 seems to have a natural level of desynchronization at the moment

This is absolutely incorrect. The most common source for seemingly random desyncs is when players who played a widgetized map before go play another map (non widgetized) afterwards without restarting WC3. If people would just stop being selfish and don't widgetize their maps, then I guess 90% of all Bnet desyncs would be gone in an instant.

^ Exactly,

I used to be a stupid mapper, I was using huge leaking triggers , calculating many things , which caused a desync since some computers can't handle that huge computing and calculating.

Just don't do huge calculating upon a very short period (0.03sec for example)... If your problem isn't solved after some time, please post a message (visitor or private) so I revise your map when I have time. Currently it all depends on you or more people to help.

Leaks and heavily overloaded scripts cause the map to start lagging and drop in FPS, but will not cause desyncs. Stop spreading false information folks!

 

[Dr Super Good]

This is absolutely incorrect. The most common source for seemingly random desyncs is when players who played a widgetized map before go play another map (non widgetized) afterwards without restarting WC3. If people would just stop being selfish and don't widgetize their maps, then I guess 90% of all Bnet desyncs would be gone in an instant.

I was dropped for being out of sync for playing a non-widgitized map before and then playing the same map again, so that clearly is not the case (someone who was with me in the last session who also did not restart WC3 was not dropped and kept with everyone else). Additionally people are usually dropped in groups. Meaning that more than 1 player ends up in two different synchronizations (tell me the chances of that when they all come from as good as random games before?).

Many years ago I had the stupid situation where both my brother and I were playing WC3 maps together. We played the same sessions since starting WC3 and I ended up split into a different session than him accompanied by someone else with me while he remained with everyone else. Both our WC3 clients were the same settings, running Windows. Clearly these out of sync errors are semi-random.

Leaks and heavily overloaded scripts cause the map to start lagging and drop in FPS, but will not cause desyncs. Stop spreading false information folks!

If the previous session you played had them then it might depending how the client deals with it. In any case it cause virtual address fragmentations which is a source of non-deterministic input into clients so can cause game synchronization to fail.

Which raises another good argument. What if there is a major game error (accessing non-allocated memory) yet it does not crash because the addresses were valid? The garbage contained in that memory will not be deterministic between client even if they do not play widigitized maps and as such could cause them to out of sync if it has any affect on gameplay. Hence it is possible all these random out of sync errors are some client error which no one knows about that does not result in a crash but instead feeds randomness (in the form of non-initialized memory or not allocated memory) into the game state.

 

[Crystalknoct]

desync at map init can have multiple reasons; for example, getting the PlayerSlotState at map init.
All of those desyncs are usually avoidable, except the one that is caused by widgetizer.

Unfortunately, there is no way to convince mappers not to use widgetizer. Scrubbing of 3 seconds of load time seems more important than ensuring that people don't have to restart WC3 every time they want to play a different map afterwards.
Because fuck those, right?

by getting PlayerSlotState would this count?

Init

• Initialization
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Custom script: set udg_CreepTable = InitHashtable()
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • ((Player((Integer A))) slot status) Equal to Is playing
          • Then - Actions
            • Set TempLoc1 = ((Player((Integer A))) start location)
            • Unit - Create 1 The Decision for (Player((Integer A))) at TempLoc1 facing Default building facing degrees
            • Player - Add 1 to (Player((Integer A))) Available free Heroes
            • Player - Add 10 to (Player((Integer A))) Food max
            • Player - Add 450 to (Player((Integer A))) Current gold
            • Player - Add 75 to (Player((Integer A))) Current lumber
            • Selection - Select Hall Of Heroes 0068 <gen> for (Player((Integer A)))
            • Custom script: call RemoveLocation(udg_TempLoc1)
            • Custom script: set udg_TempLoc1 = null
          • Else - Actions
    • -------- Initialize Systems --------
    • Trigger - Run NPS Initialization <gen> (ignoring conditions)
    • Trigger - Run Order Test <gen> (ignoring conditions)
    • Trigger - Run Icons <gen> (ignoring conditions)
    • Trigger - Run Indestructable Doors <gen> (ignoring conditions)
    • Trigger - Run Meet the King Quest <gen> (checking conditions)
    • Trigger - Run Setting <gen> (checking conditions)
    • Trigger - Run Declaration <gen> (checking conditions)
    • Visibility - Disable fog of war
    • Visibility - Disable black mask

 

[Bribe]

No desync there, but get rid of nulling that location. It's only necessary to remove the location, and nulling is only needed on local variables once they can no longer be referenced.

 

[Chaosy]

No desync there, but get rid of nulling that location. It's only necessary to remove the location, and nulling is only needed on local variables once they can no longer be referenced.

I think Maker proved that not nulling globals leaks too but it was really minor.

 

[Bribe]

You'd have to never use the global again. A variable like TempPoint1 is gonna get used indefinitely throughout the game, so there's no need.

 

[Chaosy]

That's a fair argument.

 

[jonhysone]

Leaks and heavily overloaded scripts cause the map to start lagging and drop in FPS, but will not cause desyncs. Stop spreading false information folks!

I wasn't speaking in a generalized way. However, excluding the Single-Player maps, Multiplayer maps may get desync for huge lag especially for low connection , there is some relationship between an overloaded data pack and an overloaded transferring. I was guessing 'til Dr. Super Good proved me right.

 

[Zwiebelchen]

by getting PlayerSlotState would this count?

Init

• Initialization
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Custom script: set udg_CreepTable = InitHashtable()
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • ((Player((Integer A))) slot status) Equal to Is playing
          • Then - Actions
            • Set TempLoc1 = ((Player((Integer A))) start location)
            • Unit - Create 1 The Decision for (Player((Integer A))) at TempLoc1 facing Default building facing degrees
            • Player - Add 1 to (Player((Integer A))) Available free Heroes
            • Player - Add 10 to (Player((Integer A))) Food max
            • Player - Add 450 to (Player((Integer A))) Current gold
            • Player - Add 75 to (Player((Integer A))) Current lumber
            • Selection - Select Hall Of Heroes 0068 <gen> for (Player((Integer A)))
            • Custom script: call RemoveLocation(udg_TempLoc1)
            • Custom script: set udg_TempLoc1 = null
          • Else - Actions
    • -------- Initialize Systems --------
    • Trigger - Run NPS Initialization <gen> (ignoring conditions)
    • Trigger - Run Order Test <gen> (ignoring conditions)
    • Trigger - Run Icons <gen> (ignoring conditions)
    • Trigger - Run Indestructable Doors <gen> (ignoring conditions)
    • Trigger - Run Meet the King Quest <gen> (checking conditions)
    • Trigger - Run Setting <gen> (checking conditions)
    • Trigger - Run Declaration <gen> (checking conditions)
    • Visibility - Disable fog of war
    • Visibility - Disable black mask

Yes! This is exactly what I was talking about. I highly recommend to change the event from map initialization to "elapsed game time" to prevent the slot state from getting checked before the game even started.

Doing this is indeed highly vulnerable to desyncs, especially with host bot hosted games.

I had also done this before and suffered from random desyncs at game starts... until I removed the slot state check (or at least postponed it until the session actually started). It was annoying as fuck because it made absolutely no sense. It took me weeks until I found the reason for that.

I also once had an extremely weird desync issue in the past that I could reproduce at 100% success: players actually desynced when a unit stepped on a certain tile in my map (I used WEU to import 16 tiles into my map). I'm not kidding. After I removed that one corrupted tile, the desyncs were gone.