{"push_id":2756327689,"size":6,"distinct_size":4,"ref":"refs/heads/random-hex-maps","head":"82372ae4d47562f0a76a538b4360b0cc3f802564","before":"c79f9508d28ce1932ef1006a434495e7795050fe","commits":[{"sha":"f916783427bd433aa3a5757e1d4e7e37d106c1d2","author":{"name":"Aaron Mahan","email":"5a7a6a189b47cd31d24667a751e4003cd04eced5@forerunner.games"},"message":"Fix end turn request bug.\n\nProblem:\n\n- Both PlayerEndTurnSuccessEvent & PlayerEndTurnDeniedEvent are\n  published in response to PlayerEndTurnRequestEvent due to a\n  multithreading race condition in the core module.\n\n- Both GameModel & DefaultTurnPhaseHandler have handlers for\n  PlayerEndTurnRequestEvent, but on different threads. The event is\n  received on the main thread, which is the GameModel thread, so it runs\n  first and therefore sees CacheKey#END_PLAYER_TURN_VERIFIED as not set,\n  sending PlayerEndTurnDeniedEvent in response with\n  Reason#ACTION_REQUIRED. (This occurs in spite of the GameModel event\n  handler being set to minimum priority.)\n\n- Unlike GameModel, the event handler in DefaultTurnPhaseHandler is a\n  state machine handler, so it executes on a separate worker thread\n  managed by the state machine's executor service. Therefore it runs later\n  than GameModel's event handler, although it is still a race condition in\n  the sense that the order in which the handlers will execute is\n  essentially undefined.\n\nSolution:\n\n- Remove the PlayerEndTurnRequestEvent handler in GameModel, and perform\n  all the logic for this event in the DefaultTurnPhaseHandler event\n  handler.\n\n- Remove CacheKey#END_PLAYER_TURN_VERIFIED, as it is no longer needed.\n\n- Remove PlayerEndTurnDeniedEvent#Reason#ACTION_REQUIRED, as it is no\n  longer needed.\n\n- Add a note to GameModel explaining the situation to warn future\n  developers.","distinct":false,"url":"https://api.github.com/repos/forerunnergames/peril/commits/f916783427bd433aa3a5757e1d4e7e37d106c1d2"},{"sha":"3d4e3c66df3a332111edbc594447cdb29fa44cbb","author":{"name":"Aaron Mahan","email":"5a7a6a189b47cd31d24667a751e4003cd04eced5@forerunner.games"},"message":"Fix army placement overflow bugs.\n\nProblem:\n\n- Invalid reinforcement & fortification vectors are being sent out in\n  PlayerReinforceCountryEvent & PlayerSelectFortifyVectorEvent,\n  respectively. They are invalid because they already have the maximum\n  allowed armies for their respective phases, and as such, no more armies\n  can be placed on them. Attempts to do so result in\n  PlayerReinforceCountryDeniedEvent with\n  Reason#COUNTRY_ARMY_COUNT_OVERFLOW & PlayerSelectFortifyVectorDeniedEvent\n  with Reason#TARGET_COUNTRY_ARMY_OVERFLOW being sent out, respectively.\n\n- These bugs do not crash the game because the denials are handled, but\n  they can cause it to hang for AI, if an AI player chooses to reinforce\n  or fortify a specific country, no matter what. While the denials could\n  be handled by selecting a different country or vector, respectively,\n  unfortunately if this is the ONLY \"valid\" country or vector available,\n  it will result in a hang, and the extra AI logic for dealing with all\n  possible scenarios with workarounds becomes cumbersome.\n\nSolution:\n\n  Initial Reinforcement Phase:\n\n  - Don't send reinforcement countries in PlayerReinforceCountryEvent\n    already having max armies, which mirrors what is already done for\n    regular reinforcement phase.\n\n  - If there are no valid countries remaining for a player to reinforce,\n    skip said player's reinforcement \"turn\".\n\n  - If there are no valid countries remaining for any player to reinforce,\n    end initial reinforcement phase.\n\n  Fortification Phase:\n\n  - Don't send fortification target countries in\n    PlayerSelectFortifyVectorEvent already having more than max allowed\n    armies for fortification (according to\n    GameRules#getMaxArmiesOnTargetCountryForFortify).\n\n  - Fortification phase will already be skipped if there are no valid\n    fortification vectors (source + target); now it will also be skipped if\n    the removal of target countries having more than max allowed armies for\n    fortification leaves zero valid vectors.\n\n  - Add unit tests verifying the above solutions.","distinct":false,"url":"https://api.github.com/repos/forerunnergames/peril/commits/3d4e3c66df3a332111edbc594447cdb29fa44cbb"},{"sha":"fdbc303998822e17a372eea1f25a828ca3381a50","author":{"name":"Aaron Mahan","email":"5a7a6a189b47cd31d24667a751e4003cd04eced5@forerunner.games"},"message":"Add random hex play map type.\n\n- Doesn't work yet, but PlayMapType.RANDOM_HEX is now recognized\n  throughout the playmap loading system.\n\n- The next step is the actual procedural generation of playmap data on\n  the server, then procedural rendering on the client.","distinct":true,"url":"https://api.github.com/repos/forerunnergames/peril/commits/fdbc303998822e17a372eea1f25a828ca3381a50"},{"sha":"a896e7579e381d343877055c5ff1398cad4ee7da","author":{"name":"Aaron Mahan","email":"5a7a6a189b47cd31d24667a751e4003cd04eced5@forerunner.games"},"message":"Change WinPercent to LOW, MEDIUM, HIGH.\n\n- Host specifies a win percent relatively as either low, medium or high.\n  The GameRules instance will then calculate the actual win percent\n  number. This gets around the requirement for the client to know the\n  exact valid win percents up front before connecting to the server, and\n  it also simplifies the UX.\n\n- The settings are skewed closer toward the max win percent of 100,\n  since higher win percents are more fun, in the sense that too low win\n  percents end before the game has developed and player turn order becomes\n  the deciding factor in who wins.\n\n- The low setting will be halfway between the min & max win percents.\n\n- The medium setting is halfway between the low setting and the max win\n  percent.\n\n- The high setting is the max win percent.","distinct":true,"url":"https://api.github.com/repos/forerunnergames/peril/commits/a896e7579e381d343877055c5ff1398cad4ee7da"},{"sha":"97b3db1c691ff01d99e5583dc471d3affa14a773","author":{"name":"Aaron Mahan","email":"5a7a6a189b47cd31d24667a751e4003cd04eced5@forerunner.games"},"message":"Fix win percent bug in LocalGameServerCreator.\n\n- Fix bug where win percent number was being passed in\n  LocalGameServerCreator to the server process instead of the win\n  percent enum.\n\n- Pass the win percent enum via the GameServerConfiguration in #create\n  method instead of the win percent number.","distinct":true,"url":"https://api.github.com/repos/forerunnergames/peril/commits/97b3db1c691ff01d99e5583dc471d3affa14a773"},{"sha":"82372ae4d47562f0a76a538b4360b0cc3f802564","author":{"name":"Aaron Mahan","email":"5a7a6a189b47cd31d24667a751e4003cd04eced5@forerunner.games"},"message":"WIP: Random hex client play map","distinct":true,"url":"https://api.github.com/repos/forerunnergames/peril/commits/82372ae4d47562f0a76a538b4360b0cc3f802564"}]}
{"actor":{"display_login":"3xp0n3nt"}}