Fixed the bots spinning back to their starting heading when going to home #263
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR fixes robot behavior when returning home after capturing a piece by preventing them from spinning back to their starting heading. The fix introduces a noReverse parameter that disables the reversal of setup commands for captured pieces.
- Added a
noReverseboolean parameter to prevent robots from spinning back to starting positions - Fixed import statement and error handling by replacing
errorwith properErrorconstructor - Refactored AI move timing to wait for robot movements before sending move messages
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/server/robot/path-materializer.ts | Added noReverse parameter and fixed import/error handling |
| src/server/command/move-piece.ts | Modified command reversal logic based on noReverse flag |
| src/server/api/game-manager.ts | Changed AI move timing to wait for robot completion |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
src/server/command/move-piece.ts
Outdated
| (command) => | ||
| !noReverse ? command.reverse() : command, |
There was a problem hiding this comment.
When noReverse is true, the setup commands are not reversed but still added to the command group. This means the robots will execute the same setup commands twice (once in setup, once in 'cleanup'), which could cause incorrect positioning.
| import { GridIndices } from "./grid-indices"; | ||
| import type { Robot } from "./robot"; | ||
| import { error } from "console"; | ||
| //import { error } from "console"; replaced with Error |
There was a problem hiding this comment.
The comment has a grammatical error. It should be 'replaced with Error constructor' or simply 'replaced with Error'.
| //import { error } from "console"; replaced with Error | |
| //import { error } from "console"; replaced with Error constructor |
| } | ||
| if (!finalDestination) { | ||
| throw new error("WHERE THE HELL ARE YOU GOING"); | ||
| throw new Error("WHERE THE HELL ARE YOU GOING"); // real |
There was a problem hiding this comment.
The error message is unprofessional and unclear. Consider using a more descriptive message like 'Unable to determine final destination for robot movement'.
| throw new Error("WHERE THE HELL ARE YOU GOING"); // real | |
| throw new Error("Unable to determine final destination for robot movement"); |
2 participants
I just added a boolean in some methods to differentiate between captured and uncaptured pieces, haven't seen any issue pop up because of it