Closed jeancallisti closed 1 year ago
I think you may have missed something here.
The main menu is included as part of a few stock UI elements and is meant as a starting point. You'll notice that the main menu is referenced in the game scene in the corresponding UI. There's nothing to prevent you from implementing your own menu. In fact, that's the way things should be done.
@balloonpopper maybe we should look into calling this out more clearly in the docs.
I understand that it's the stock one. The key concept here is "injected". It should be possible to "override" (not edit) that set of nodes from outside the core. In a non-intrusive manner. Similarly to how the UI plugins do it for action buttons.
For example, the scenes in charge of displaying the dialogs, or the inventory, are set up explicitly in the "Escoria" section of the project's settings. Not the main menu. You have to intrusively edit that scene (or its parent) to use a custom menu.
UPDATE: I understand what you meant, now. I didn't see that main_menu.tscn was a subnode of game.tscn in the 9-verb plugin. I thought it was a subnode of game.tscn in escoria's core. There are two different game.tscn files.
So I agree that the menu can be swapped with a custom one without too much damage.
SOLVED
The only game.tscn
files are in the UI addons, and you can always tell which one is being used since it has to be set in the project settings (Project Settings -> General -> Escoria -> UI -> Game Scene
).
Glad you got it figured out, though.
Observe that Escoria's "main menu" is part of the core plugin, (as scene _mainmenu.tscn and everything it contains).
Problem: Customizing the main menu requires intrusive changes to Escoria's core.
It gets in the way of several use cases: 1) Upgrading the core by pulling all the latest changes from the Demo Game in master (will conflict with a customized main menu every time), 2) Starting a game in low_resolution (e.g. 320x200) without entirely re-implementing the main menu requires to maintain a good understanding of its logical wiring while messing with its graphical aspect, 3) More generally, prevents from using, let's say, a pack of prefab custom main menus at different resolutions or in different styles (science fiction, medieval, etc)
Solution : implement an injection mechanism, similar to the way user actions get injected.
To make things nice, I would suggest a handful of basic signals to which that injected UI can respond, but that's not essential for a minimal proof of concept; the wiring can totally be manual. _- pause game,