Arx Libertatis Bug Tracker
Please log in to bookmark issues
OPEN  Feature request #134  -  You should always be able to exit to the main menu
Posted Nov 15, 2011 - updated Oct 02, 2012   Shortlink:
Issue details
  • Type of issue
    Feature request
  • Status
  • Assigned to
    Not assigned to anyone
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     Daniel Scharrer
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Not determined
  • Priority
    Not determined
  • Severity
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Not determined
Issue description
Currently, opening the main menu is blocked sometimes:
  • in a conversation (makes issues like #99 much more annoying)
  • during cutscenes
  • when the player is paralyzed (happens often during lich fights)

This should be changed that the player always has the option to immediately open the main menu (and thereby pausing the game) without disturbing the game state (ie: cutscenes and conversations should not be skipped).

  • The current save system might not work correctly when the player is in a conversation/cutscene - this should be fixed.

Comment posted by
Nov 15, 05:20
"block_player_controls" could be removed from conversation checks and whatever else is needed to always allow the user to escape from conversations - regardless of fade status or whatever else.

eventually it would make sense to use space (or, more logically, the activate key including controller buttons) to skip through conversation and esc would always return to the menu while fully pausing the game state.

of course we'd need to implement an activate control first.
Comment posted by
 Daniel Scharrer
Dec 01, 00:08
I like the idea of reserving escape for exit to main menu and using space to skip cutscenes / conversations. However we would either need to block the "Save" menu entry or fix the savegames to store enough cutscene / camera / conversation state.
Comment posted by
Dec 01, 05:48
i think blocking the "save" menu entry might work... an alternative might be to save immediately before entering a conversation assuming that isn't too expensive and using that data for the save if the user requests it inside a conversation.

modern systems of course have a "menu" key/button directly on the controller so esc need not be the only option.

if only the ui code were not in such a mess. i have a feeling this might be an area i'll focus on soon...
Comment posted by
 Daniel Scharrer
Dec 01, 13:12
Saving is still too expensive to do an autosave before every conversation.

I think the best solution would be to be able to save in the middle of conversations / cutscenes and then resume from there when loading. But that is something to do later - just blocking the save menu entry could even be done before the first release.

Edit: things we can do to speed up saving:
  • Only re-save interactive objects that actually changed (many items / static objects rarely change). We'd need to track changes to interactive objects first though.
  • Split the compression/writing of saves (see SaveBlock) into a separate thread.