Post round actions

[corygehr]

Adds the ability for a player to perform additional actions after the end of a round (ex. save data to a file, output results, etc.). Useful for applying machine learning to a player.

Not sure if you'll want to create a wrapper for this function to prevent crashing/timeouts from a player who fails to implement it properly. I attempted to do this, but with how callPlayerFunction() works it'll throw a NullPointerException since it's checking if the player has been disqualified (and at the point where I've called the function, the gameboard object has already been destroyed).

[davidswelt]

Maybe this should be called before the gameboard object is gone, because the player might want to do something with it. That would take care of the issue with calling via callPlayerFunction(), which I think is a good idea (because students' code cannot be allowed to crash the tournament).

[corygehr]

Good point! I'll open this back up and make that change.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: David Reitter notifications@github.com Sent: Friday, April 14, 2017 8:35:55 AM To: davidswelt/wolvesandsheep Cc: Cory Gehr; Author Subject: Re: [davidswelt/wolvesandsheep] Post round actions (#17)

Maybe this should be called before the gameboard object is gone, because the player might want to do something with it. That would take care of the issue with calling via callPlayerFunction(), which I think is a good idea (because students' code cannot be allowed to crash the tournament).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/davidswelt/wolvesandsheep/pull/17#issuecomment-294175538, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABHmVnBssKlcEVEwvzzwlJoZCoUZpWqsks5rv5JbgaJpZM4IsDP0.

[corygehr]

@davidswelt Took me about a year but it should be good!

[davidswelt]

Thanks Cory!

On Mar 29, 2018, at 5:29 PM, Cory Gehr notifications@github.com wrote:

@davidswelt Took me about a year but it should be good!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[corygehr]

I seem to have forgotten to call this via callPlayerFunction(). Unfortunately, this means it's started throwing NullPointerException again in some cases, namely, when the player is no longer on the GameBoard and the round is ending.

This is thrown because when a player has been removed from the game, its internal 'gb' object is set to null (presumably because it's no longer needed - the player isn't on the board anymore). This is problematic because you're calling isDisqualified() any time callPlayerFunction() is invoked which references that object.

I mitigated this in my most recent commit by storing the scenario number locally in setGameBoard() and referencing it where needed instead of gb.scenario.requested. It seems to be working, both in a single round and multiple rounds with random scenarios.

Do you see any problems with this? Since these are private variables I believe I've caught any situation this would change, but I wanted you to be aware in case I missed something else.

[davidswelt]

Other than that it’s quite a bit of a hack …?

I think there might be a reason why gb is set to null. Probably to prevent access when it’s really invalid. But I would think that the player should be able to see the game board during post round actions, no?

On Mar 29, 2018, at 7:39 PM, Cory Gehr notifications@github.com wrote:

I seem to have forgotten to call this via callPlayerFunction(). Unfortunately, this means it's started throwing NullPointerException again in some cases, namely, when the player is no longer on the GameBoard and the round is ending.

This is thrown because when a player has been removed from the game, its internal 'gb' object is set to null (presumably because it's no longer needed - the player isn't on the board anymore). This is problematic because you're calling isDisqualified() any time callPlayerFunction() is invoked which references that object.

I mitigated this in my most recent commit by storing the scenario number locally in setGameBoard() and referencing it where needed instead of gb.scenario.requested. It seems to be working, both in a single round and multiple rounds with random scenarios.

Do you see any problems with this? Since these are private variables I believe I've caught any situation this would change, but I wanted you to be aware in case I missed something else.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[corygehr]

@davidswelt I agree. You still can access the GameBoard in roundEnding() if you've created a property for it in a Player implementation and populated it via getGameBoard(). Based on the included basic players this seems to be an implied practice to follow, but it does cause an issue if you try calling getGameBoard() in roundEnding() for a player that's already been removed from the game. You already check if gb is null in that function to ensure players aren't calling it from their constructor though so it wouldn't cause additional problems.

The GameBoard object causing the NullPointerException is within Player.java itself and that's where it's set to null when a player is removed from the board. It doesn't impact a GameBoard in inheriting classes so you can still use the GameBoard is desired.