search

LARG / HFO

Half Field Offense in Robocup 2D Soccer
MIT License
231 stars 93 forks source link

Defense agent assigned unum 1, behaves as goalie, while unum 2 npc is purple in soccerwindow2 #34

Open drallensmith opened 7 years ago

drallensmith commented 7 years ago

I've been doing a bit of work on the defense agent, and have discovered that - roughly 50% of the time - it gets assigned unum 1. As far as I can tell, because the formations are by numbers, the unum 2 npc - which is purple (goalie) in soccerwindow2 - does not behave like a goalie (leaves the goal area), while the unum 1 agent sticks around the goal (either because of the formations in doMove, because the goal is otherwise wide open and this is triggered by Reduce_Angle_To_Goal, or a combination of the two), despite being colored red (normal rhs player) in soccerwindow2. I will try to figure out where the unum-assignment logic is to make sure that no non-goalie is put in unum 1.

drallensmith commented 7 years ago

As it turns out, it's 50% of the time for a python defense agent (that I'm currently in the process of writing) - it's closer to 100% for the cpp agent, which starts up faster. Trainer.py probably would manage to start things up at the right time for the right unum... if it were what was launching the agents. As it is, if one only waits 5 seconds after starting up HFO (which starts up the server first), at least on my machine the agent starts up before the Trainer starts up any of the defense npcs, winding up with the agent frequently as having unum 1. I've changed the delay to 15 seconds and it's currently working for the cpp agent, and should work likewise for the python agent. Admittedly, this is very machine-dependent and python-version-dependent...

mhauskn commented 7 years ago

Good observation. It's good that the 15 sec delay helps, but it would be nice to have a more principled method for starting these agents.

On Mon, Jul 17, 2017 at 9:35 AM, Allen W. Smith, Ph.D. < notifications@github.com> wrote:

As it turns out, it's 50% of the time for a python defense agent (that I'm currently in the process of writing) - it's closer to 100% for the cpp agent, which starts up faster. Trainer.py probably would manage to start things up at the right time for the right unum... if it were what was launching the agents. As it is, if one only waits 5 seconds after starting up HFO (which starts up the server first), at least on my machine the agent starts up before the Trainer starts up any of the defense npcs, winding up with the agent frequently as having unum 1. I've changed the delay to 15 seconds and it's currently working for the cpp agent, and should work likewise for the python agent. Admittedly, this is very machine-dependent and python-version-dependent...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LARG/HFO/issues/34#issuecomment-315802463, or mute the thread https://github.com/notifications/unsubscribe-auth/AABNOTNEcRCqQmQ2Wwi2oHi1N27M6IRVks5sO4wBgaJpZM4OaG2c .

drallensmith commented 7 years ago

Agreed. I'll put a note in the startup script about why the 15-second delay, BTW.

-Allen