Godoku v0.3.6

Update

Update 0.3.6 is focused mainly around adding animations to the menus. You know, pizzazz!

• Menu animations. Whooooo!
• Misc fixes, refactors, etc.

Godot Dev

The Interesting GUI Stuff

That's a small update list, but it turned out to be more complex than we predicted.

Originally, our in-house modal menu system handled hiding and showing itself as part of its natural lifecycle, but when adding animations, we needed to open up that lifecycle to additional handlers.  By adding signals on modal.gd for `request_show` and `request_hide`, we can plug in any kind of transition we want. Replicating our original show / hide just means connecting `CanvasLayer.show()` / `hide()` methods into the signals.

That's where we bring in the excellent Simple GUI Transitions addon by joelgomes1994. It gives you immediate polish by animating your menus with no intervention on the part of the programmer.

Unfortunately,  it isn't fully compatible with our modal menu system. The root node type of the modal menu is `CanvasLayer`, because we value the convenience of the `CanvasLayer.layer` index moving an entire tree "up" and "down" in the drawing stack. The Simple GUI Transitions class `transition.gd` expects its reference var `_layout` to be type `Control`. So we made a new transitions system with some inspiration from joelgomes' work.

This mostly involves adding new signals and making connections between nodes through the editor, without each node needing to "know" about others or store references to them. This approach is very flexible, can hook back into nodes requesting transitions, and allows designers to do more of the work in the editor without needing new code to be written each time.

The Frustrating Engine Stuff

The signal approach stores the signal connections in the scene file. If you like dependency injection, you'll love it. But! as of Godot 4.2, we've had a lot of issues with the editor simply not recognizing some of the contents of scenes, including signal connections!

The most egregious case involved a base scene, an inherited scene, and an instantiation of the inherited scene within a menu scene. The base scene's signals worked, the inherited scenes signals worked, and we verified that the instantiated scene had signals working in the editor and appearing in Node.signal_name.get_connections() as late as the _ready() event. Then they mysteriously disappeared by the first _process() callback!

Nothing in documentations, forums, discord, etc had ever mentioned this, so we started taking the scene apart piece by piece. As far as we can tell, the scene file hadn't updated to include inherited signal connections -- despite them appearing in the editor -- so they were being overwritten on the first frame. By simply deleting and re-instancing the scene, everything worked without any further intervention. This seems to line up with some scene corruption problems other people have had in their upgrades from Godot 3.x to 4.x, in particular 4.2. 

So we traded out the 4.1 audio crackling issue for a 4.2 design-time issue, which is better for users, but this presents practical workflow challenges. While the New Inherited Scene function makes a lot of sense, the scene corruption issues have made it hard to rely on.