TODO: Make it possible for one script to control 2+ players (mainly for testing)

[drallensmith]

For testing purposes, it would be convenient to enable one script to control more than one player. Instances include:

• 31 (Note that part of my logic on that one is that even the high-level random agent is effectively given information about whether Move vs Dribble/Shoot is applicable)

• 33 (To help in comparing results between high-level and low-level feature sets)

Currently, trying this (via 2 hfo.HFOEnvironment() calls, then using the results of these to do separate connectToServer calls) errors out with that the strategy is already initialized; I suspect other places would have problems also.

I am going to start trying out a workaround using python's multiprocessing module and separate processes. (Threads do not generally work very well on cpython (or on pypy), due to the Global Interpreter Lock.)

[mhauskn]

I agree this would be a good thing to have. In general, it is difficult because the rcssserver expects agents to each have separate processes and all of the existing code is built around this assumption. In C++ I've controlled multiple agents from a single script using threads.

[drallensmith]

A correction on the above, BTW - that's what happens if one forgets to change --offense-agents to 2. (Oops...) If one does change that, it instead hangs while waiting on a select call for the second agent to connect, possibly because they're using the same port. An option to specify the agent-side port might help; will try to look into that later if you think it could work.

[tpbarron]

@mhauskn would it be possible to create an example of controlling multiple agents in C++?

[mhauskn]

I've added an example: https://github.com/LARG/HFO/blob/master/example/thread_agents.cpp

[nosyndicate]

@mhauskn , would you be able to give a python example for the same purpose?

[drallensmith]

As his first response mentioned, it would be rather difficult with the current code. I can try to work up my existing two-process scripts into something more readable by others.

[nosyndicate]

@drallensmith , that is great, would you mind list which of these example code are for this kind of use?

[drallensmith]

I'll try to do so this weekend - lots of other stuff going on right now.

[nosyndicate]

@drallensmith , really appreciated!

[drallensmith]

@nosyndicate: Take a look here - sorry about the considerable delay. The main multiprocessing part of the script is in the last two functions (and also requires the imports at the top regarding multiprocessing). Note that in order to actually access shared values, you can't just access the variable itself (that will get you the proxy itself, not the value it is relaying); you need to access the .value attribute.

Incidentally, note also that the branch the script is on is based off of a distance-correcting patch branch, without which it will give even more warnings of inconsistent measures than it would otherwise, and may error out if these are extreme enough; see #42 for the pull request to integrate this patch with LARG/HFO.