vaiterius / traditional-roguelike Goto Github PK

It seems that on my terminal emulator, I'm getting this error when trying to run the game using python 3.11.2 on MacOS. It seems that the loop overfills the pairs array. I'm not a python dev so I don't know much about the language or curses, so I'm not sure if the loop should go from 0-255 including 255. The error says greater than 255, so it's possible that it's looping from 0-256 unintentionally.

I hope this does not come off as a nitpick, since it's just my honest report on first-hand usage.

What I did:

• Clone, run
• Notice I can't open a menu in "exploration" state
• Go to README
• Find "main menu" hint
• Found:

  To go back to main menu:

  - m

Which ATM is not working.

I later realised there's also:

To exit:

- Q

Which asks to go to main menu as promised. I understand why you would not want an immediate-quit key (user may press it by accident when playing), but in my opinion the exit key should close the game altogether (after a "confirm" prompt, I'd prefer) while the menu key should bring you back to main menu.

I would open a separate issue to describe the fact that the exit key brings you to main menu, but that may be intended behaviour.

At the moment, the error display for too small of a screen is not always drawn correctly.

I think at the moment, the whole thing blows up if the screen's width is less than the error message.

This occurs on main branch whenever a call to ensure_right_terminal_size() finds a weird enough screen:

[... Omitted]
^^^^^^
  File "/repos/Traditional-Roguelike/game/terminal_control.py", line 1199, in display_main_menu
    self.ensure_right_terminal_size()
  File "/repos/Traditional-Roguelike/game/terminal_control.py", line 1535, in ensure_right_terminal_size
    self.screen.addstr((x // 2) + 1, submessage_ypos, submessage)
_curses.error: addwstr() returned ERR

When trying to run from patch #5, this error may occur as soon as the game is launched (given a screen size "small enough").

I guess error handling for the addwstr() call in self.screen.addstr((x // 2) + 1, submessage_ypos, submessage) may alleviate this, maybe falling back to a minimal size that ensures something is drawn and no crash occurs.

I'm mostly positive this was mostly me messing with the resizing, but I wonder what's the actual condition needed to make the drawing fail.