Players race wrongly displayed as Unknown

[GoogleCodeExporter]

In some situations when the players race is not random it will behave as though 
it was.

I have experienced this when:
When playing Single Player -> Custom game in FFA and Melee games
When playing Multiplayer -> Local PC in a One on One game, but only on one of 
the instances, depending on which one hosted
When playing Multiplayer -> LAN in a One on One game against a computer, but 
only occasionally and it even some times knows the race of the computer when it 
was random. I have yet to find a pattern

Original issue reported on code.google.com by quaver.smith on 4 Jan 2012 at 3:40

[GoogleCodeExporter]

Oh boy! xD

Original comment by AHeinerm on 4 Jan 2012 at 7:59

• Changed state: Accepted
• Added labels: Component-Logic, Milestone-Release, Priority-Critical, Type-Defect, Usability

[GoogleCodeExporter]

Fixed in r4017, let me know if fix worked.

Original comment by AHeinerm on 4 Jan 2012 at 11:06

• Changed state: Fixed

[GoogleCodeExporter]

Looks like multiplayer is bugged with it.

Original comment by AHeinerm on 4 Jan 2012 at 11:10

• Changed state: Started

[GoogleCodeExporter]

Might be the Random Start Location that's causing it.

Original comment by AHeinerm on 4 Jan 2012 at 11:17

[GoogleCodeExporter]

It is in fact the random start location causing the issue. It took a while but 
I finally reverse engineered the code that selects random locations (the 
difficulty of the code was because of inlined functions and several unfolded 
loops).

The raw decompile: http://pastebin.com/D43yD6nj
Interpreted version: http://pastebin.com/RU3NCE3b
The cleaned version uses 2 members I added to BWAPI in r4126 for reference. 
Also char should probably be bool.

The difficulty is hooking it. There are actually 3 different functions which 
will randomize players based on different game types. The calls are all 
non-standard (since it appears to be inlined). I'll be able to find a solution 
soon.

Original comment by AHeinerm on 28 May 2012 at 2:18

[GoogleCodeExporter]

Proposed workaround: 
Because the complicated code involved in the randomization of player slots, it 
is impossible to simply map the player slots with Random as a race with player 
slots who have had their race and slot position randomized. However, the 
workaround sets a value in the player structure that can be compared with after 
the randomization occurs. Human players already have a unique storm ID while 
computer player all have the same ID "~0, or (DWORD)-1". In order to 
distinguish between computer players this value must change. The value can be 
restored after it has been mapped so that no risk is involved.

Proposed hooks:

Before: 0x004EF20E -- call to RandomizePlayerRaces [0x004A9A30]
Hooking here will allow us to determine which players are random directly 
instead of using the current workaround.

After: 0x004EF244 -- call to initializePlayerConsole [0x004EE180]

Both hooks are void __cdecl fxn(), making it easier to manage.

Original comment by AHeinerm on 9 Jun 2012 at 4:09

[GoogleCodeExporter]

Fixed in r4137

Original comment by AHeinerm on 9 Jun 2012 at 5:10

• Changed state: Fixed