Problem with SocketAI

Greetings,

we are using microrts in a small machine learning project that is being programmed in python. We use [python-microRTS](https://github.com/douglasrizzo/python-microRTS) as socket interface.

When the source code is downloaded and compiled everything works as expected in STANDALONE mode. WorkerRush beats hands down RandomBiasedAI. If we modify the source code a little bit and print the return of function getAction in WorkerRush.java we can see the bot is performing actions like

`{ (Base(20)(0, (2,2), 10, 0),produce(up,Worker)) }`

which create new workers.

Problems appear in CLIENT mode. We execute the example program [random_actions.py](https://github.com/douglasrizzo/python-microRTS/blob/master/examples/random_actions.py). Indeed, the initial worker moves randomly but the base does not produce any additional workers in spite of having enough resources. Inspection of the python program shows that the JSON string.

`[{"unitID": 20, "unitAction": {"type": 4, "unitType": "Worker", "parameter": 2}}]`

is sent every 50 time steps, which means that the base at least is being busy when ordered to produce a worker. Again printing the return of function getAction on SocketAI.java shows actions like

`{ (Base(20)(0, (2,2), 10, 0),produce(up,Worker)) }`

which is exactly the same as with WorkerRush but for some reason it is not producing workers.

While it could seem it is a problem with python-microRTS, the python part seems like it is doing its job all right and even getAction in SocketIA.java seems to understand and send the action. So the question is, why these instructions keep the base busy but do not yield workers as expected?

Any help with this issue would be greatly appreciated. Thank you very much in advance for your help.

Start by reproducing the difference between STANDALONE and CLIENT mode with examples/random_actions.py, then trace the action through WorkerRush.java and SocketAI.java, focusing on getAction and the JSON action shown in the report. Compare the logged produce(up,Worker) action with the resulting game state and identify why the client instruction leaves the base busy without creating a worker; done means the cause is confirmed and worker production behaves consistently.

Written by the indexing model from the issue text.