Occasionally, a UMS replay fails to function after a certain point, and units simply sit there and the replay breaks from that point on because the replay is trying to order units that don't exist. What could cause replays to break like this?

I've listed several suspects for this phenomenon, with the ones I am not sure of marked with a (?):
-Junk Yard Dog/critter randomizers
-Playing the game on speeds other than "fastest" and running the replay on "fastest"
-Randomized switches (?)
-Hitting map limit of units (WARNING: Unit Unplaceable) (?)
-Creating and moving a large number of units
-Laying spider mines/spawning broodlings in a location that strongly affects future game outcome (?)
-Accidental stacking of ground units (?)

Is anyone here informed about the actual cause of replays breaking? It would help immensely to know when replays break and when they do not.

Rumor has it that waits can affect replays as well.

map limit and unit unplacable are two completely different things.

I had a replay of DSNight Fixed that I was watching for a bug that I knew occurred about 40 minutes into the game. After about 3-4 minutes I saw changes from how the game had played out (helpfully confirmed with players chatting about what was going on, and the replay didn't match). The main culprit in my case seemed to be geysers not being built, which in turn gave the player less resources, so buildings wouldn't be built etc.

This glitch applied to the human players (CPU ones seemed fine), which don't really match any of your listed possibilities except for creating/moving large numbers of units (when the player spawns), but again this happens in the 'spawn buffers' while the de-sync was happening in the bases with their workers. This was particularly evident with a zerg player that only build 1 spawning pool followed by 6 extractors - in the replay it stopped at #3 and never got further. Some other players had fully proper replays up to a point, or partial replays that didn't capture all buildings they had built.

In short, it seems that *if* there is a general trigger explanation, using that(those) triggers anywhere in the map will affect the replay for all players, not just the player it was used on.

If I recall correctly, randomizing triggers used to cause defects in replays because of the way switches were randomized and the way that replays actually play. Replays play by saving actions instead of picture frames, and then recreates them as you watch. When someone randomizes a switch, replays used to actually re-randomize the switch, making it so the switches probably won't land on the same thing during play as during the replay. But, I think that was patched.

These are all one thing: Randomization. (Also @CecilSunkure) Starcraft uses the same random seed globally, so the numbers generated should be the same. It's stored in the replay header.

These events should behave the same way they did in the game. I doubt it has any effect on the resulting replay.

Just wanted to point out that critter movement is not random in the same way switches are, it's not 50/50. Critters move up about 90% more often than they move down, and move left more often than right. It's random in the sense that you don't know which of their 10 vertical movements will be their 1 down movement, but it's far from being equally random in any two directions.

Just thought I'd throw that out there as a bit of little known information that's semi-relevant to the discussion

Post has been edited 2 time(s), last time on Oct 12 2010, 12:14 pm by DevliN. Reason: Mineral abuse.

Changing the replay speed breaks it pretty nicely

@bobo: in my test of the DSNight Fixed replay, the game was played at Fastest. Changing the replay speed between 16x, 8x, 4x and 1x regular speed didn't make any difference at all to the glitches, it would still glitch in the same way each time.

And yes, I did leave the replay running at 1x speed from the very beginning to confirm that.

If I remember correctly, putting a wait in the map, for example 2000 milliseconds, and then running the replay at, 2x speed for example, it'll still wait for 2000 real milliseconds instead of 2x that. I think I was told this so I'm not confirming this.

I've heard that a replay that was made using an older version of starcraft wouldn't work that well.

Tested; no, triggers still run at the same rate.