Brainstorming desyncs

[Sud]

I'm currently dealing with a reoccuring desync issue which likes to manifest itself on people during the final phase of the game, namely when they're destroying the remainder of the enemy base.

I've been looking around to find some of the sure causes of desyncs, though the standard ones people seem to know about are pretty few. My options on troubleshooting it are limited, because my map runs more off an "engine" than it does individual triggers, thus it's not viable to test by disabling triggers (and of course there's the added issue of being able to actually do the test as it's a multiplay issue). The best theroy I have at the moment is that it may be linked to the amount of units being created per wave of creep and the orders being given to them, but I'm not sure.

This thread is to share ideas on desyncs and to see if I can get a rapport going between people who have had them and found out methods in which to identify and fix them. Seems to me it'd be a good idea to have "one big thread" for these big types of issues (for example, 0xC0000005 crashes might be a good candidate for one of these).

 

[XXXconanXXX]

Give us detail as to if there is a pattern, (When a certain building dies, etc.) and any triggers you have that could go along with it.

 

[Sud]

That would be nigh impossible, the complexity of the map is such that there can be literally be dozens of things going off at once.

It does not have a set cause and effect, sometimes it doesn't even occur at all, but when it does the only pattern I've been able to lock down is that it occurs near the end of a game in the enemy base. This leads me to believe that it may be an issue that there are too many units, or too many orders being issued to units simulataneously. The map is designed to flow smoothly with 300 units, up to around 500 units. I believe it will start chopping out on my machine at around 600ish, though it rarely achieves that kind of overhead.

So it's really difficult to do the normal troubleshooting such as disabling triggers or giving you an isolated case.

Thus why I am looking to establish some rhetoric in this post related to this topic - just get a feel for what people have experienced as cause and effect for desyncs in their map.

 

[XXXconanXXX]

Units can crash the game, but not desync. I've played a few gam,es of ToB when creeps flood, having a good 600 units in the base pouding on the Castle and it doesn't cause to many problems. (Just lags a bit)

Different actions and functions put together can cause desyncs. Cinematic mode causes desyncs in certain cases, so if you ARE able to isolate the problem, then you'd have to work around it and fake that function.

If your triggers are repetitive and memory leaks pile up with unoptimized triggers, that can REALLY contribute to desyncs. Make sure your destroying points, locations, unit groups, player groups, etc. so they're not piling up and causing the desync.

When you get to the score screena nd after you have pressed the quit button, does it take a while to head back to the chat screen of Battle.net? If it does, then you have quite a handful of memory leaks.

 

[Sud]

I am destroying unit groups and locations, though one thing I haven't been destroying and maybe I should be is unit facings, ie. Create 1 Footman at TempPoint facing Position of Hero.

Wasn't sure if the facings of points would cause leaks, but they probably do considering it seems any reference to an unvariabled point creates an undestroyable leak. Something worth trying at least.

I found that leaks were a pretty large source of 0xC0000005 crashes though. That has pretty much gone away.

 

[Sud]

Wow, nobody else's had problems with desyncs eh? That's pretty fortunate.

 

[Darg]

give people more time, you're welcome to bump this thread once a day.

Make sure you are not destroying global variables, beacause you are asking the game to crash on you big time. If you assign a unit group or location into a global variable, you do not need to destroy it because there is no memory leak there - because you put it into a variable! When in doubt, just assign it to a global variable first, it saves so many complications, and it also makes for better code too (i.e. forget about destroying anything!)

And last I checked, memory leaks don't make the game crash, all they do is start to lag it badly after some time. Back in the day I might have had some theories why your game crashes, but these days the editor code is much more stable, so its likely something fancy you are trying to do with triggers is causing it (like destroying variables!)

 

[Sud]

Oh wait, global variables. Yar I don't destroy udgs

Do you happen to know if say, a flurry of commands to a unit might cause people to be disced?

One question, do facing of unit positions cause leaks?

ie. Create one Footman at TempPoint facing of position of Hero (leaky?)

Create one Footman at TempPoint facing of HeroPoint (not leaky?)

 

[Darg]

One question, do facing of unit positions cause leaks?

I don't know, and to be frank, I don't really care. I think the mapping community is getting just a bit too obsessed with memory leaks. Everywhere you go you see people asking "does this leak?" or "does that leak?". What I am encouraging people to do is to stop asking such questions, and to instead ask "Is this good coding?" or "Is this bad coding?". If you code something properly, you won't even need to care about memory leaks, beacuse you will already account for them by writing good code.

Example:

Good code -

set TempPoint = Random point in <region>
set HeroPoint = Random point in <region2> offset by <x,y>
Create one Footman at TempPoint facing HeroPoint
Create one Rifleman at TempPoint facing HeroPoint

Bad code -

Create one Footman at (Random point in <region>) facing (Random point in <region2> offset by <x,y>)
Create one Rifleman at (Random point in <region>) facing (Random point in <region2> offset by <x,y>)

Why is the above bad code? Well if you change your mind and decide you want the footman and rifleman to be created at a different point facing a different angle, you now have to go and change the creation point and facing angle for both units, every time you change your mind! And you may also start getting paranoid that what you have done might cause memory leaks!

In the good code example, all you have to do is change the TempPoint and HeroPoint variables, and in one go you have instantly applied changes to all trigger actions that use those variables! And it won't leak!

So in summary, the good code has the following advantages:

- Saves huge amounts of time if you have many trigger actions using the same sorts of functions
- Saves huge amounts of time if you decide to change things around
- Stops memory leaks dead in their tracks, because you have assigned everything to global variables
- Makes your code unbelievably more readable

Hopefully you understand what I am trying to say.


Now, back to the topic of desyncs. Unlike memory leaks, the blame for desyncs lies less with the mapper and more with the game.

A couple of known causes of desyncs:

- Using the "camera - pan camera as necessary" trigger action
- Setting unit/building sight ranges to zero

Some theorized (but not confirmed) causes:

- Setting any object editor number field to an insanely large value (e.g. setting a unit's attack damage to 99999999)
- Issuing large numbers of attack-move commands in rapid succession

If I can think of any more I'll add to the list.

 

[XXXconanXXX]

And last I checked, memory leaks don't make the game crash, all they do is start to lag it badly after some time. Back in the day I might have had some theories why your game crashes, but these days the editor code is much more stable, so its likely something fancy you are trying to do with triggers is causing it (like destroying variables!)

I contest that.

Local variables LEAK. If you do not rid their values and destroy the leaks, then they will leak. They will also crash if you null something like a point, Unit Group, or Player Group variable before you destroy the leak. Pointers also leak as well, even after you null a variable or derstroy the leak, the pointer in the handle is still there.

Example:

Good code -

set TempPoint = Random point in <region> set HeroPoint = Random point in <region2> offset by <x,y> Create one Footman at TempPoint facing HeroPoint Create one Rifleman at TempPoint facing HeroPoint

Bad code -

Create one Footman at (Random point in <region>) facing (Random point in <region2> offset by <x,y>) Create one Rifleman at (Random point in <region>) facing (Random point in <region2> offset by <x,y>)

Globals variables take up space and will lag as much as leaks, so it's better to just destroy the location rather than making a global variable for it, unless you want thousands of globals variables. (I would)

 

[Darg]

Local variables LEAK. If you do not rid their values and destroy the leaks, then they will leak. They will also crash if you null something like a point, Unit Group, or Player Group variable before you destroy the leak. Pointers also leak as well, even after you null a variable or derstroy the leak, the pointer in the handle is still there.

yep, no argument there. I wasn't talking about locals in that case, I was suggesting he might be destroying global variables, which would crash the game if you went to use them after destroying them.

Globals variables take up space and will lag as much as leaks, so it's better to just destroy the location rather than making a global variable for it, unless you want thousands of globals variables. (I would)

why would you create thousands of global variables to do what I proposed? you only need one per variable-type, and you only need them for things like unit group, player group, point, etc. You may have 5-6 global variables at most to pull this off effectively, and that won't make much of an impact on anything.

 

[Sud]

Good discussion, thanks guys.

My map is modelled after the "good code" example - with the exception that I'm DestroyPointing the global point variable after each use. A long time ago I wasn't and the map was noticably laggier.

The most likely cause of the desync would be the possible attack move command stackups. I have a lot of units being created at certain times, and the units are further encouraged to attack move on certain regions of the map, to prevent them running back to base (some issue occurs where they'll just decide to drop their order and head back to base). The most units usually occur on the map near the end of the game, which is usually a large number of GG creeps pounding at the enemy base, and that's when the desyncs like to manifest.

 

[XXXconanXXX]

why would you create thousands of global variables to do what I proposed? you only need one per variable-type, and you only need them for things like unit group, player group, point, etc. You may have 5-6 global variables at most to pull this off effectively, and that won't make much of an impact on anything.

Eh, you misunderstood me.

I meant I'd rather use a simple JASS code to destroy leaks rather than using globals just to get rid of leaks.

Plus, with temp globals, if your overusing them, they can overwrite eachother.

The most likely cause of the desync would be the possible attack move command stackups. I have a lot of units being created at certain times, and the units are further encouraged to attack move on certain regions of the map, to prevent them running back to base (some issue occurs where they'll just decide to drop their order and head back to base). The most units usually occur on the map near the end of the game, which is usually a large number of GG creeps pounding at the enemy base, and that's when the desyncs like to manifest

The reason creeps run back is because they have damaged 'themselves' (Retracking hit points rather than damaging them) or by an ally. If they reach their destination, they automatically go back. Stop this with a simple trigger to check if the attacking unit is an ally, then issue the order, or just use the native damage function rather than manually taking away hit points.

 

[Shadowy Fear]

Why is it called a memory leak? Shouldn't it be a memory drain? AHAHA I'M SO FUNNY *Looks around, notices no one else is laughing, slides back into chair*

I'm just curious, what is a desync?

 

[XXXconanXXX]

Whedn the connection is severed between the players. Can be cuased by severe lag or something within the game that severes the connection between the host and the players. (The host is usually not booted)

Memory leak is when a peice of information that SHOULDN'T be there in the first place gets to a point where it's iretreivable, and msot of them are small thing. They can pile up and cause severe lag later on and it takes a LONG time to exit the game becuase the server is dumping the memory.

 

[Darg]

Plus, with temp globals, if your overusing them, they can overwrite eachother.

they would only possibly do that if you stick a wait in between setting the variable and using it. It is NOT possible for them to overwrite each other in the absense of the aformentioned wait. Any typical example of using a temp global in the situations I mentioned before are unlikely to ever have waits between the setting and using of the variable. And if they do, all you have to do is either set the temp global after the wait, or just set it again. easy.

My map is modelled after the "good code" example - with the exception that I'm DestroyPointing the global point variable after each use.

what does "DestroyPointing" mean? I think I know what you're saying anyway.

 

[XXXconanXXX]

He's talking about destroying the point within the global.