Draft: Update debug scenario and robot detail modal #2395
Conversation
* rename to debug.yaml to match scenario name * tweak map so that it is easier to see where the robot should crash * change crashed robot log hint so that it does not have line breaks inside sentences * change hint robot code, so that it does not spam logs * use more available space in robot detail pane to make the log readable * use hexadecimal time format in `Tick` pretty instance
xsebek
added
the
CHANGELOG
| iterate n com; | ||
| end; | ||
|
|
||
| tydef RobotState = [gave_win: Bool, said_log_missing: Bool, said_loc: (Int * Int)] end; |
|
Looks like the CI is failing because |
xsebek
changed the title
|
I will add a few more improvements, stay tuned! 📀 |
| zoomRobots $ do | ||
| removeRobotFromLocationMap oldLoc rid | ||
| addRobotToLocation rid newlocWithPortal | ||
| unless invis $ wakeWatchingRobots rid t newLoc |
There was a problem hiding this comment.
@kostmo I would like to change the watch to also notice robots. I want to avoid system robots having to busy-wait, and this would help a lot.
But to do this radical change, I would need help. Four challenges that use watch fail with this change, and I am unable to decipher how they work:
- Challenges/gopher
- Challenges/Sliding Puzzles/3x3
- Challenges/Ranching/capture
- Challenges/Sokoban/foresight.yaml
Could you please check if the solutions could work with waking by (visible) robots?
I thought about making a new command for compatibility, but that would need a new watch map. If possible, I would like to avoid the mental overload of too many commands both for players and developers.
| Before you send your robots far away from the `base` you need to learn how | ||
| to figure out what went wrong with them if they crash. |
There was a problem hiding this comment.
@byorgey I am considering adding an objective to salvage a built robot in the same space first.
I worry that this scenario teaches too much at once.
What do you think?
There was a problem hiding this comment.
Sure, I think that makes sense.
* rename to debug.yaml to match scenario name * tweak the map so that it is easier to see where the robot should crash * change the crashed robot log hint so that it does not have line breaks inside sentences * change hint robot code so that it does not spam logs * use hexadecimal time format in `Tick` pretty instance * use more available space in the robot detail pane to make the log readable * closes #2228 * part of #2392 * split from #2395
Tickpretty instance