W3G->W3GS

[Chavo]

Project Goal
Host and 'replay' a warcraft3 replay file as a multiplayer custom game on battle.net.  Because warcraft3 replays are essentially just instructions for the engine to play the game over, it should be possible to use a replay file to instruct the engine to perform similar actions in a multiplayer context.  The W3GS protocol is known well enough to have determined that the action packets are extremely similar to the action blocks used in the warcraft 3 replay format which makes this even easier.

General process overview

• parse replay file for player information, map filename, action list, and chat
• create battle.net lobby with player information and map signature
• allow human players to join as ghosted observers (they cannot see each other so as to avoid player-id limitations)
• start game and inject modified actions & chat at the correct times

The problem
I currently have this process working with one catch: actions are injected properly but ignored by remote clients.  I have determined that this issue is almost certainly because of a specific portion of the data in an action block.

this is an example action block as it exists in the replay file

1F              timeslot block, contains action block (see w3g_format.txt, w3g_actions.txt)
2B 00          length of data to follow
FA 00          time in milliseconds since last interval
01              player ID of the action
26 00          action block length
16              action ID: change selection
02              select mode
01 00          number of objects
74 71 00 00  objectID1
76 72 00 00  objectID2
16              action ID: change selection
01              select mode
01 00          number of objects
26 73 00 00  objectID1
40 74 00 00  objectID2
1A              action ID: pre subselection
19              action ID: select subgroup
38 30 30 6E  itemID (constant)
26 73 00 00  objectID1
40 74 00 00  objectID2


The action block portion of the data follows the same format for W3GS packets with some differences in header data which is easy to create.  The issue here is that the objectID values are, at my best guess, relative memory pointers.  The objectID values for the objects created at map startup at the same for a given map.  When new objects are created, their assigned objectIDs may not necessarily be the same.  Generally they can be the same if the same sequence of events happens (I believe time itself is not important, which strengthens my belief that these point to memory locations).  Furthermore, once an object has been assigned ObjectIDs, they do not change.  Objects of the same type (acolytes, for example) will have the same offset between objectIDs which makes sense since two acolytes should take up the same amount of space in memory.  Different units/buildings will have different offsets.  When I say offset, I mean the difference between objectID1 of two sequentially created objects of the same type.  At this point, I do not have a strong opinion regarding the importance of the second objectID. Sometimes it is the same as objectID1, sometimes it is not.

The challenge here is to determine if it is possible to alter these objectIDs in such a way that the clients will be able to use the memory pointers correctly (seems unlikely if initialization isn't predictable) or to manipulate the game setup in such a way that the objectIDs will be correct for players watching the game.

I attached a zip file with some of my example data that I've been generating.  Any insight on this objectID challenge would be appreciated.