Maps with many players, units, and triggers sometimes desynchronize, instantly dropping 1 or more players. Anyone know how to diminish this? Are there certain triggers or actions that make it more likely?

Some extended stuff going on? EUDs? Extended supply? Extended units? Anything?

If it isn't extended supply or extended units as NudeRaider was thinking, my guess is it's CCMU related. Those are the only desyncs I've had that happen consistently.

Nothing extended is going on, no CCMU is going on. It's a lot of conventional stuff. I can upload the map if you'd like to look at it. The unit count never gets past 1300.

I don't think CCMU is intrinsically an issue either, I think it has to do with lots of unit creation and removal happening. That's the only commonality I have seen across games where this happens. Which include Diplomacy Maps, Melee Money Maps, etc.

Here's a similar case: http://www.staredit.net/topic/16338/

Though it seemed to have been solved after removing a standard doodad. I will confirm with OP.

I do not use any preplaced sprites or doodads. I do use some extended units like the "Unused" Zerg *Scouts (Units -> Zerg -> * -> Unused). I use Aldaris and Arcturas. I've seen this crash in other maps not using these.

Post has been edited 3 time(s), last time on Apr 27 2017, 9:45 am by Veta.

Are you counting double units appropriately? Siege tanks (tank and siege mode) and goliaths (and hero versions) count as two units each and can sneakily cause CCMU. From the thread you linked: This trigger will completely fail to work on any map with neutral units or double units. Counting units accurately is pretty fucking trigger-intensive, actually. One semi-accurate unit counter I did has ~1100 triggers, and that's with counting double units at intervals of 5. Perfect counters require a lot more.

Anyway, my guess is still that you're reaching CCMU, even with a unit count of "only" 1300. A map I was having CCMU issues with was hitting it as low as 1100 on my unit count, which really fucked with me until I learned the above. Another thing to know is that if you're creating and removing a bunch of units, those units persist until the index is updated, and can also cause CCMU errors. Units in production but not built yet are also assigned an index number. Accurate counts thus also have to include *when* and *how often* you count -- and should ideally factor in production and removal as well. Extended units, ccmu, and lots of unit creation and removal all causing desync point to a buggy indexer though.


Here's a post on the index that explains how it works in more detail:
http://www.staredit.net/topic/14230/

Something about the way starcraft is handling this index causes desync.

Post has been edited 1 time(s), last time on Apr 27 2017, 12:11 pm by outlawpoet. Reason: posterity

Interesting theory, but don't you need to see the words "Cannot Create More Units"? I have never seen this on the map. If not then aren't we talking about something else? i.e. An index issue where indexes are limited to 1700 but recycling is not working correctly?

I recently changed the max unit limit from 1200->1350, it almost never hit 1200 and I made it 1200 to test the theory that it had to do with high unit counts. We're talking about 500 spare indexes here. Including siege tanks and everything else I don't think we hit 1700 unless there's something awry not functioning as intended. There are only ever 60 tanks on the field.

Thanks for the knowledge though, I will mention this in a bug report on the SCR forums.

You can hit CCMU with 0 units on the map if you create and remove them in the same trigger cycle, it wouldn't be hard to have 500 index IDs unaccounted for with your unit count. And you can reach CCMU and desync without ever seeing the message unless you try to build something yourself. The "Cannot create more units" message is linked to your actions, not the map state.

I see, I still don't see how it's possible for hundreds of indexes to switch in a trigger cycle for this map, several triggers only fire every 2, 3 or 5 cycles. But let's assume it does happen.

Why would it cause a desync rather than CCMU which is normally what happens? Why do some maps never drop and others do despite reaching CCMU more frequently? Doesn't this all point to other factors?

Playing devil's advocate.

I believe there is an undocumented bug in Brood War that desyncs players. It is somehow related to terrain or doodads. I don't know the details unfortunately, but I still have one of the maps I made that suffers from this problem. I noticed that players in my map would instantly drop, a slew of them, maybe 1-4 players. I also noticed it kept happening around the same area of the map. After some tinkering I deleted whatever terrain was around that area and replaced it all by hand. Afterwards the bug disappeared.

My suggestion is to keep track of where players screens are when this happens. A desynchronization will occur when two players have data sent to each other over the network that does not match. A bug in StarCraft code can definitely cause this problem -- garbage data can eek its way into the net data. If you know roughly where players are or what they are doing, you can try to modify your map in that spot to avoid the bug.

I'm more like to believe CecilSunkure, because Create Unit and Remove/Kill Unit never caused a desynch, unless they've really (really!) messed everything up to this point in 1.18.

To detect CCMU you don't need to count anything. One can make a trigger that attempts to create a unit at a predefined place every several seconds and the next trigger that detects the created unit. If the second trigger fails then the map reached CCMU and it's time for some clean up.

CecilSunkure, if you still have the map it would be interesting to identify the cause of the desynch.

Yes Cecil, if possible please share the two different versions with as much information as possible for investigation. If we can document this we can report it and have it fixed.

I don't have the old version, just the fixed one. I can dig it up and post it when I get home, unless I forget to post it.

I have no idea how to prevent existing desync but I do know one thing that consistently causes it. Protecting and unprotecting a map repeatedly consistently creates a desync problem. I've seen it happen to several maps by now. Regarding CCMU, I implemented a remove unit when CCMU system in the attached map. All the triggers are commented so it's easy to find the ones labeled anti hoard. It was 5 years ago that I did it but I seem to remember that a CCMU detection system needs to run every other trigger cycle, same cycle detection doesn't work.

Attachments:

I recommend removing all sprites and testing a couple times like that; it's the easiest layer to modify-and-test and has worked (as you know) in my case and in one other persons.

100% false. This is exactly what causes desync in Diplomacy Gold, and it's been doing it for as long as I've played the map. Here's a specific trigger example to reproduce desync with in CCMU conditions:


Trigger("Player 1","Player 2","Player 3","Player 4","Player 5","Player 6","Player 8"){
Conditions:
Bring("Current Player", "Buildings", "002", At least, 1);
Bring("Foes", "Buildings", "002", Exactly, 0);
Bring("Allies", "Buildings", "002", At most, 0);
Command("Current Player", "Terran Marine", At least, 1);
Bring("Current Player", "Buildings", "019", At most, 0);
Bring("Non Allied Victory Players", "Buildings", "002", At most, 0);

Actions:
Preserve Trigger();
Create Unit("Current Player", "Hunter Killer (Hydralisk)", 1, "147");
Remove Unit At Location("Current Player", "Terran Marine", 1, "147");
}

//-----------------------------------------------------------------//

You get an "unable to create unit" error and multiple players desync. Without a gentlemen's agreement to keep unit counts low, this happens every single game with more than two players. Always in CCMU conditions.


Detecting CCMU after it's already happened is a pretty terrible way to prevent the bugs it causes when it happens.

on edit: I'll share my unit counter(s) with people if they want, it's a lot of annoying binary countoffs. It should go in a separate thread though since CCMU and desync aren't 1:1 correlated as there are other known causes.

Post has been edited 1 time(s), last time on Apr 28 2017, 6:10 am by outlawpoet.

No sprites on the map. But I decided to look at the map in CHKDraft and check for any doodad-tiles. I found a few and removed them. I will test tomorrow.

Cecil, do you remember if the offending tiles were doodad-tiles or could they have been any regular jungle tiles? If the latter I will need to change terrain drastically to test.

There's the rub. I intuitively know the desync drops happen when there's a lot of things on the board and a lot of unit creation and removal happening. And it seems like terrain plays a role too. It is terribly confusing. I will be testing the theory that doodad-tiles are a necessary requirement for desync.

Ok, no dice. Removing doodad tiles did not change desync. Intuitively the only conclusion I can come to is that it does have to do with unit indexing, or something else weird.

Interestingly, on Fish, the map behaves differently. I'll see two of something spawn when the triggers only allow for one. I wonder why that is. Behavior is as expected on USEast.

outlawpoet, do you have a map that you can 100% reproduce desync on? What about with only 2 players?

Not only do I have a map, I probably have multiple dozen replays of broken games from it. As I said it happens literally every single game in Diplo Gold.

What conditions are required? Can you do it with 2 people? How long does it take? Can you make a test map that cuts down this time?

You mentioned a CCMU counter, did this in any way help with preventing desync? How would it?