allow player to modify popup during game#13698
Conversation
|
I think the concept of customizable menus has merit. Does this work at the counter level or the prototype level? I'm assuming at the counter level since prototypes have all been expanded at the point you working. Doesn't this mean you have to make the same changes to every single counter you touch? Sounds a bit painful?
To undo this, you will have to iterate through the children until you find an instance of MenuDisplayer and remove it. We could also modifiy the source in 3,.7,16 to something like this: addChild(gerMenuDisplayer()) to make it easier to over-ride. |
|
About any other module needing this… yes and no from me, I have modules with lots of menu items but I design in the nested menus in what I hope will be a useful structure, or at least it will be a consistent experience. I guess VASL demands a more personal approach or the existing menus can’t readily be changed? A question on the PR, is the customised menu a local view or does it get replicated into the log? |
|
I implemented successfully a few months ago in VASL, the operation does not have to be repeated for every counter and the state is saved so it keeps even after closing and reopening the module. If you guys are interested I can show you the code or you can just look at the VASL repo. |
| final List<KeyStroke> strokes = new ArrayList<>(); | ||
| final java.util.Map<KeyCommandSubMenu, JMenu> subMenus = new java.util.HashMap<>(); | ||
| final java.util.Map<String, List<JMenuItem>> commandNames = new java.util.HashMap<>(); | ||
| final JMenu unwantedMenu = new JMenu("Unwanted"); |
There was a problem hiding this comment.
"Unwanted" - should be translatable with an entry in Properties (update: I realise now, probably not, as the usage here is internal).
However, it would be more useful if the special sub-menu name were user-configurable and if any submenu could be used in this way; e.g. by a checkbox on the submenu trait that makes the submenu a possible target for user customisation, which would free the feature from depending on a hard-coded submenu name.
| // Menu text & behavior can now be custom-classed without needing to override the monster that is MenuDisplayer#createPopup. | ||
| protected static JMenuItem makeMenuItem(KeyCommand keyCommand) { | ||
| final JMenuItem item = new JMenuItem(keyCommand.isMenuSeparator() ? MenuSeparator.SEPARATOR_NAME : getMenuText(keyCommand)); | ||
| final CustomMenuItem item = new CustomMenuItem(keyCommand.isMenuSeparator() ? MenuSeparator.SEPARATOR_NAME : getMenuText(keyCommand), keyCommand); |
There was a problem hiding this comment.
From my limited knowledge of MenuDisplayer etc, I read this PR as effecting a Custom Menu that, set by any player, will be visible to all other players. Is that desirable as a generic feature?
3 participants
I have implemented a function to allow the player to modify the popup menu during gameplay to deal with the problem of some menus being way too long. Basically, I created an "unwanted" menu and the player can move items to that submenu during gameplay to reduce clutter and customize as he likes. The code is currently functional but needs more work, I was just wondering if this is a feature that any other game actually needs.
If not then I will implement in the VASL code which is probably doable if not ideal. What would be the best way to remove the following element added by the Map class
within the ASLMap class so that I can add my own ASLMenuDisplayer()?