How are PIDs assigned?

[GraylinKim]

For basic XvX ladder games this is pretty straight forward but there are a number of alternate game scenarios that people are bound to run into:

This game is a 1v2 AI that seems to assign PIDs as follows:

Team 1:
    Player 1 - Tzuqris
Team 2:
    Player 3 - A.I. 2 (Very Easy)
    Player 4 - A.I. 3 (Very Easy)

This game is a 1v2 humans that seems to assign PIDs as follows:

Team 1:
    Player 1 - Brothus
Team 2:
   Player 2 - Collision
   Player 3 - goatsonfire

This game from 1.2.2 (didn't have a newer example on hand) is a 1v1 with 6 observers. Correctly assigning ids to observers is important for things like chat messages and is required for correctly mapping game events. The linked replay isn't a great example because there is no observer chat, maybe someone can find a better one.

[dsjoerg]

I believe ( @GraylinKim correct me if I'm wrong) that it would be sufficient to tell us where in the replay structure we could find the PID for each player, rather than knowing exactly by what method they are assigned.

[GraylinKim]

Yes @dsjoerg , if they are directly stored in the replay that would be fine.

If they are derived from replay details and initData then we would need to understand how to do that properly.

[koalaling]

The short answer is there's no great way to do this right now; it requires information from the map file to compute player ids. However it's a good idea to add new tracker events in a patch to record the mapping between player id, user id and lobby slot id.

To explain those terms: "Players" are a game simulation concept; they only apply to human participants and AI (as of patch 2.0.4 observers are not assigned player objects). "Users" are a network session concept and include all humans (both participants and observers, however not AI) . "Slot ids" are a lobby concept where starting conditions are recorded (for AI and human participants and observers).

As of 2.0.4 (Base build B24944) each game event records the user id of the sender; in previous builds we recorded the player id instead. We probably should have recorded m_userId in the tracker events instead of m_playerId to be consistent, but we could also just provide the mapping between players, users and lobby slots.

For any particular map you can figure this out. If you open the Editor, navigate to the Data module, then choose Map | Player Properties you'll see the list of players available in the map. Copy down the player id (left column) in order across every row that has the Control column equal to User or Computer. Then iterate the initdata's m_lobbySlot.m_slots array from a replay made on that map - if the m_control == 2 (user) or == 3 (computer) then peel off a player id from your map player id list. The slot also contains the m_userId (for human participants) so you now have a mapping between player id and user id. This might be useful for stable, popular Arcade maps that you want to analyze replays from. Ideally though we will patch the game to put this info directly in the replay.

[GraylinKim]

Thanks @koalaling, this was very helpful. I'll leave the ticket open as a reminder to improve in this in a future patch.

[GraylinKim]

Unfortunately @koalaling, I can't seem to make the technique described above work for the 1v2AI linked in the original post here.

The map (Arid Wastes) has a standard Player Properties layout:

#   Control
0   Neutral
1   User
2   User
3   User
4   User

The slots in the replay look like this:

0: control=2, user_id = 0
1: control=0, user_id = None
2: control=3, user_id = None
3: control=3, user_id = None

Following the above, I would expect that the following was true:

Tzuqris - player_id = 1, user_id = 0
A.I. 2 (Very Easy) - player_id = 2, user_id = None
A.I. 3 (Very Easy) - player_id = 3, user_id = None

But tracker events recorded in the replay are found to have player ids of 1, 3, and 4!

Can you help me out here @koalaling?