I'll be checking this out. Thanks, homie.

Hi, I have a few games under my belt now, but by no means an expert. I am quite fond of the change_scene_to_packed method on the scene tree. It clears the current main scene and replaces it with your new scene while maintaining any singletons (autoloaded scenes). Feel free to look at how I did it for last years GMTK game jam: https://git.techiedamien.xyz/TechieDamien/Ouroboros/src/branch/master/Scripts/main_menu.gd

You can also clone it and edit it to see how it works. Feel free to ask me any questions about it.

This is immensely helpful, thank you!

I do indeed want a pause screen with similar behavior so that tidbit is perfect.

I wouldn't call myself a veteran by any sense, and it'd be helpful if you posted a screenshot of your scene tree so we can see what you're working with. A few notes:

Generally speaking it's recommended to keep scenes and their associated scripts in the same directory. You can subdivide your /scenes directory further, as well, to organize things, but really your structure is up to you and whatever works for you is fine.

Consider making one "Main Menu" scene, and adding all of the sub-menus as children. Rather than adding and removing children, you can just hide / show them as needed. The increased resource usage to keep them all in the scene tree at once is extremely minimal and should have exactly zero impact. This also makes it easier to, for example, show the menu over a paused level if the user presses Escape (or whatever button you use), and it makes it easier to assign references to the sub-menus, using exported variables.

(If you add @export before a variable declaration, the variable shows up in the Godot editor when you select the node the script is attached to, and you can assign values there. This creates dynamic references to e.g. scenes, and if you move the scene in your folder structure or the scene tree later, it will automatically be updated. With the 'hard coded' paths you're using currently, you'll need to manually go and update those references any time your file structure changes.)

I'd use a simple state machine to manage this. A very basic implementation is to have a "states" enum with your various states (e.g. MAIN_MENU, OPTIONS, LEVEL_SELECT, etc.), and a "current_state" variable. Make a 'change_state' function that has 3 components:

1. 'Exit' the current state. This is where you run any code that needs to happen when a state ends - for example, when you exit Options, you want to hide the Options menu node, etc.
2. Change the state, where you actually set the state variable to the new value
3. 'Enter' the new state, where you include code related to the new state starting - for example, for Options, this is where you Show the window (and maybe run an initialization function inside the options menu script, if needed).

It's a very compact way to keep all of the code in one place and make it very easy to add new states or functionality later. For the project as a whole, you might want to consider a more robust state machine if it warrants it.

Edit: here's a quick and dirty example of what a (very basic) state machine might look like for a single thing like this:

enum States {
	NONE,
	MAIN_MENU,
	OPTIONS,
	LEVEL_SELECT
}
var current_state = States.MAIN_MENU

func change_state(new_state:int) -> void:
	# Exit state
	match current_state:
		States.MAIN_MENU:
			main_menu.hide()
		States.OPTIONS:
			options.hide()
			options.save_options_to_disk()
		States.LEVEL_SELECT:
			level_select.hide()
			set_next_level(level_select.chosen_level)
	
	# Set state
	current_state = new_state
	
	# Enter state
	match current_state:
		States.MAIN_MENU:
			main_menu.show()
		States.OPTIONS:
			options.show()
		States.LEVEL_SELECT:
			level_select.show()

You can use a similar state machine to handle (for example) player actions - have states for Jumping, Running, Walking, Standing, Climbing, etc., and use the state machine to both start and stop animations as needed, and to gate input (to prevent, for instance, jumping while already jumping.)

Edit #2: Without seeing the rest of your code it's hard to say if this applies, but just as a note: If you're removing scenes from the scene tree, then re-instantiating them the next time you need them, you're potentially creating a memory leak. You either want to store references to the scenes after you remove them, and just re-add them to the scene tree, or you want to free them (via queue_free()) which actually removes them entirely and frees up the memory they were using, then reinstantiate them later. (Removing children doesn't actually remove the scene from memory.)

Sorry, I didn't read through all of your code. But the beauty of Godot is that you can take any node and its children and save it as its own scene to be reused in other scenes. That makes refactoring easier when you discover later that you actually want to set up everything differently.

damn wish I knew about that xr jam sooner, two days late now!

The simplicity is why I prefer this one, Terrain3D has a lot of features I dont need

TerraBrush is quite nice. Not as complex as other terrain editors, but good and easy to use for basic terrains.

@teaHead74 Terrain3D is your best bet at this time, if it matches your requirements.github.com/TokisanGames/Terrai

Idk, i think it's much more effective to spriongle the dinglang with a sminkinant, of course you'll want to use excelsior to provision the brumgle for maximum convenience.

It can be a real fight to upgrade. Why duke it out with the code when you don't need to?

... How about a total revamp and expansion and improvement of the IK system in 4.6?

Also, 4.7 will probably be finalized within 6 weeks, at the rate they're going.

Also also, I'm fairly sure the jump from 4.5 to 4.6 didn't like, break anything.

There's new stuff, and then if its meant to replace old stuff, the old stuff is still there, just tells you its deprecated now, depending on your console/warn settings.

I know we take forever with projects but there really isn't a reason to upgrade once you're well on your way right?

Don't nuke your codebase chasing engine updates.

Unless there's a specific thing you need in the newer versions, there's no point upgrading. Use the framework you started with. Make your next project with the new framework.

True. In hindsight, I probably could have stuck with 4.4, too.

Sounds like overkill for a game project, but I'll consider it for my plugin project (even though it's meant mainly for greenfield projects so my current support plan is "only latest release and maybe the one before it if someone actually asks")

Yeah, otherwise development might take forever...

or just, you know, don't update unless you need to

It's often not worth keeping up with engines unless there's specific features you'll need.

Kinda wish they had an LTS version

i didn't like ∆V, but i almost loved it. i thought it was neat that you could hire crew that gave different bonuses depending upon their specialty and experience. i thought it was neat that your crew can recognize other folks you come across in the rings. i thought it was really neat when one of those strangers told my crewmate about an anomalous lidar contact they made further in.

as i got closer to coordinates they shared, tracking this enormous lidar contact: it occured to me that if the developers had seized upon this moment with eldritch horror that it would be my favorite game ever. i felt scared, if that rock turned around and had an eye and then a dozen rock tentacles busted into my ship and squeezed all the blood out of my crew -- it would have been my favorite game.

Also Brotato

Nice to see another great Godot project. This, dome keeper, and ∆V doing the work out here.