Replay Explorer

Summary
Replay Explorer is a program which allows you to inspect and modify warcraft 3 replays. It is written in vb10, and requires the .net 4.0 Release Candidate (note: uninstall .net 4.0 beta 2 first). The source code is available at the github page. Most of the format stuff is actually specified in Tinker, which you can also find under my GitHub account.

Uses
- Quickly find less-obvious replay info (eg. who left when, who said what, etc)
- Update the version of an old replay, allowing warcraft 3 to replay it (perhaps inaccurately, but better than nothing)
- Take a replay showing a bug in your map, retarget the replay to a fixed version of the map, and see if the bug is really fixed
- Satisfy Curiosity

More Information
In the course of writing Tinker, my host bot, I've done a lot of work on the small details of the replay and game action formats used by warcraft 3. I'm pretty sure I have the closest spec on them outside of Blizzard. So I decided to write a simple program to read replays, which turned into Replay Explorer.

Replay Explorer is extremely strict about its input data. It won't try to guess at what the replay means, it will just stop parsing with an error explaining what went wrong. That's to force you to tell me about it, ultimately making our understanding of the format better.

End
Note: The installer might fail if you don't already have .net 4.0 RC installed. If it fails, just install the framework beforehand then try again.

Source code?

All the heavy stuff is in Tinker (which is used as a reference assembly). This is just a quick 150-line interface on top of it. I can put the source code in this post (well, I guess this technically doesn't include the placement of the controls and stuff). It's not particularly good, but I wrote it in a few hours.

*Edit* The code is now available on github (see main post)

Replay Explorer can now, to a limited extent, edit replays.

In particular, it can:
- Update a replay's version, allowing it to play under the current version of wc3. (The resulting usable replay may not play out exactly like the original game, depending on how wc3 has changed.)
- Change the map a replay targets. This is intended for bug testing. Essentially, a player finds a bug, and sends you a replay. You fix the bug (applying an extremely small change to the map), retarget the replay to the fixed map, and check that the bug no longer occurs in the replay.
- Manually edit the raw data of individual replay entries. This one isn't user friendly at all, but it has some advanced uses. For example, in the last version of wc3, I figured out how the invincible tower hack worked by adjusting some build order flags and confirming that the replay now showed a player making an invincible tower.

I've also updated parts of the format since the last version, so the descriptions and such will be better.

I did some work and the edit entry form now dynamically generates a control to edit anything it knows how to parse. It's pretty neat. Main post updated.

My current plans are to address the limitations on editing. For example, you can't add/remove items in lists (eg. selected units) and you can't change key-prefixed values (eg. actions or the entry type itself).

I also have to change some of the formats to no longer use the "InteriorSwitchJar", which parses data differently based on some key value in the middle of the data, because it's essentially impossible to allow editing those values without causing errors.

After that I'll probably start figuring out some unknowns by changing their values and seeing what warcraft 3 does differently because of it.

Today I ran across a new replay entry, which appears to be exactly the same as a Tick. Odd.
I also found out that the unknown 0x23 value actually signals that a desync happened! The new formats, as will as the fixed editability stuff, will be in the next version.

New version posted. All entries are 100% structured editable, and the PreTick/Desync entries are included.

This is very cool. Not sure why it won't work with my map though. Can a parser be made to detect who trained what unit and when?

What do you mean, it doesn't work?
- It hits an error loading replays from your map.
- It hits an error trying to retarget to/from your map
- It shows unit ids like 'A000' and you consider that not working

The error occurs when loading replays from my map. So I guess this can already record when individual units are trained? Must have missed that.

Post the replay, and the map too. You just ran across a flag I haven't seen before. You can see it in the message: "1<<1" (aka the second bit).

I expect to get a lot of these types of error at first, as people run a wider variety of replays than I've seen through the tool.

Map and a replay.

That replay is generated by ghost, which might be deviating from the file format a bit. I'll ask Varlock about it. I'll also relax the restriction on that value, so it allows unrecognized flags.

Are you using a map config, or letting ghost compute the values automatically? If you're using a map config, I think you entered your map game type incorrectly.

I looked at the relevant code in ghost, and it looks fine (at least in terms of not putting a 2 (= 1<<1) for game type). However, it does have an inaccurate comment on the value.

Hidden information: Code: ** in map config generator code ** tmpcfg << "# map game type" << endl; tmpcfg << "# 1 = custom" << endl; tmpcfg << endl; tmpcfg << "map_gametype = " << "1" << endl; tmpcfg << endl; ** in replay saving code ** Replay.push_back( m_MapGameType ); // GameType (4.7) Replay.push_back( 32 ); // GameType (4.7) Replay.push_back( 73 ); // GameType (4.7) Replay.push_back( 0 ); // GameType (4.7)

My definition of the map game type:

Hidden information: Code: <Flags()> Public Enum GameTypes As UInteger None = 0 Unknown0 = 1 << 0 '[always seems to be set?] '''<summary>Setting this bit causes wc3 to check the map and disc if it is not signed by Blizzard</summary> AuthenticatedMakerBlizzard = 1 << 3 OfficialMeleeGame = 1 << 5 PrivateGame = 1 << 11 MakerUser = 1 << 13 MakerBlizzard = 1 << 14 TypeMelee = 1 << 15 TypeScenario = 1 << 16 SizeSmall = 1 << 17 SizeMedium = 1 << 18 SizeLarge = 1 << 19 ObsFull = 1 << 20 ObsOnDeath = 1 << 21 ObsNone = 1 << 22 MaskObs = ObsFull Or ObsOnDeath Or ObsNone MaskMaker = MakerBlizzard Or MakerUser MaskType = TypeMelee Or TypeScenario MaskSize = SizeLarge Or SizeMedium Or SizeSmall MaskFilterable = MaskObs Or MaskMaker Or MaskType Or MaskSize End Enum

Combining those code fragments, I can work out that, by default, ghost is assigning maps a game type of:
1 + 32*256 + 73*256*256
= 1<<0 + 1<<5*1<<8 + (1<<0+1<<3+1<<6)*1<<16
= 1<<0 + 1<<13 + 1<<16 + 1<<19 + 1<<22
= Unknown0, MakerUser, TypeScenario, SizeLarge, ObsNone

That's very close to the game type in your replay. In fact, the first byte is just off by 1. That byte is determined by the value of m_MapGameType, which is loaded from the config value "map game type", which has a misleading comment stating that 1 means 'custom', which I believe led you to change the '1' to a '2' for some reason.

Am I right?