Conversation
ivet1987
commented
Aug 29, 2026
ivet1987
commented
Contributor
- Create explicit event loop for asyncio to fix RuntimeError in Python 3.14
- Replace asyncio.ensure_future() with loop.create_task()
- Pin pyglet to <2.0 for API compatibility
- Create explicit event loop for asyncio to fix RuntimeError in Python 3.14 - Replace asyncio.ensure_future() with loop.create_task() - Pin pyglet to <2.0 for API compatibility Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Check if websocket exists before closing to prevent AttributeError. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Show all 8 robots on welcome board for selection - Only selected robots (up to -p parameter) are placed on game board - Game starts when all selected players confirm their cards - Modified Server.__init__ to create all robots as available but inactive - Modified assign_robot_to_client to place selected robot on start position - Modified confirmation check to count only assigned robots Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- All robots (8) are now created in game state but initially inactive - Robots become active when assigned to players - Welcome board shows all robots (state.robots) with available ones highlighted - Fixed confirmation counting to only count active robots - Game starts when all active/assigned robots confirm their selection Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Use Direction.N instead of integer 0 when creating/deactivating robots Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Skip drawing border for robots with None coordinates (inactive robots) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- All robots now have coordinates from the beginning (visible on map) - Added is_active flag to distinguish selected vs unselected robots - Robots stay at their positions even when not selected - Only active (selected) robots participate in the game Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Only robots selected by players are visible on the game map Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add is_active to as_dict() and from_dict() for proper network transfer Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Send robots_as_dict() to update map viewer when robots become active/inactive Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Filter out inactive robots from the player list in interface Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Ensures game_state is initialized before receiving robot updates Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Robots start with coordinates=None (not on map) - When selected by player, robot gets coordinates (appears on map) - When disconnected, robot gets coordinates=None again (disappears) - Frontend filters robots by coordinates != None instead of is_active - Simpler and more reliable than separate flag Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add handling for 'robots' message key so map updates when players select robots Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
When play_round() was called, it tried to process all robots including those not yet selected (coordinates=None). These robots don't have dealt_cards attribute, causing AttributeError. Now filtering to only process active robots (those with coordinates) during game rounds. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add max(0, ...) protection to ensure timer display never shows negative seconds, even if game processing takes longer than expected. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
set_robots_for_new_turn() was processing all robots including those never selected by players. When it called find_free_start() on inactive robots, it would assign coordinates to unselected robots, making them appear on the map. Now skipping robots with coordinates=None. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Previous fix incorrectly blocked ALL robots with coordinates=None, including active players who fell into holes or off the board. Now using start_coordinates[0] to distinguish: - Never selected robots: start_coordinates[0] is None (skip these) - Inactive players: coordinates=None but have start_coordinates (resurrect) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Change LOG_FRAME_TIME from 0.2 to 0.5 seconds to make robot movements easier to follow visually. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…nding on flag Moved flag collection from end of register (apply_tile_effects) to during robot movement (walk method). Now robots collect flags as they pass through flag tiles, not only if they end their move on the flag. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
repair_robot was logging state change which caused visual glitch at start of new round. Repair is silent change, no need to log. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
When robot dies, it now returns to the position where it started the previous round, not to the last flag visited. Simpler and more predictable behavior. - Added round_start_position attribute to Robot - Updated find_free_start to use round_start_position - Save position at start of each round in play_round Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problem: Server was sending final robot state AFTER the animation log, causing client to display end position before playing the animation. This created the "jump to end and back" visual glitch. Solution: Remove redundant robots_as_dict() message - the log already contains all states including the final one. Also fixed collect_flag to not add duplicate positions to start_coordinates. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problem: When server sent "robots" message, client called reset_last_robots() which set the animation starting point to the final state. Then when log arrived, it animated from final state back to start, causing the visual glitch. Solution: Don't call reset_last_robots() when receiving "robots" messages. Let the log animation handle all transitions smoothly. Also moved reset call inside the log_to_play check in tick_log(). Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Root cause: Receiver was updating state.robots from "robots" messages, which set robots to final position. Then log animation would start from this final position, creating the "jump and back" glitch. Solution: - Receiver now ignores "robots" messages completely - Added record_log() when robot is assigned (appears on map) - Send log when robot is assigned so receiver sees it appear - Receiver only uses log for all robot position updates - Interface client still uses "robots" messages as needed Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Line 133 had == (comparison) instead of = (assignment), so custom robot names entered by player were never actually saved to the robot. This caused the name to reset back to default after each round. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problem: last_robots was storing references to robot objects, not copies. When robot state changed during animation, the reference changed too, causing wrong robot to be displayed (e.g., green Marvin instead of blue Bender). Solution: Create deep copies of robots using as_dict/from_dict serialization so animation baseline is preserved even when robot state changes. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.