Create a loading screen after clicking on the main menu buttons #169

Closed
opened 2026-08-30 11:24:45 +00:00 by metaheavens · 1 comment
Owner
No description provided.
Author
Owner

Done in 0fad1dd.

ui/LoadingScreen.gd: a cover over the menu with the name of what is opening and a bar that moves. It goes up on the press and the load only starts once it has been on screen for a frame or two, so the frame that blocks happens with something visible rather than behind a menu that has stopped responding.

Two notes on what it deliberately does NOT do:

  • The load is still the ordinary blocking one. ResourceLoader.load_threaded_request() was the obvious way to get a real progress bar and it does not work here: asked for these scenes it comes back FAILED, with the text-scene parser reporting errors ("Parse Error ... Rock.tscn:9", "Could not resolve external class member PROFILES") that the same files do not produce through load(). The scripts and scenes reach each other through global class names and preloads, and that resolution is not available off the loading thread. A progress bar is not worth a menu that sometimes refuses to start the game - and the web build ships with thread support off anyway, so it could never have used that path.
  • So the bar is a sweep rather than a percentage. It reports "working", not "this far", because there is nothing honest to report.

A second press while a load is running is ignored. On the web a button fires on PRESS (see IconButton), so an impatient double tap costs nothing to make and used to build the world twice.

Covered in test_main_menu.gd: the cover is up and the menu is still the current scene immediately after the press, and further presses change nothing.

Done in 0fad1dd. ui/LoadingScreen.gd: a cover over the menu with the name of what is opening and a bar that moves. It goes up on the press and the load only starts once it has been on screen for a frame or two, so the frame that blocks happens with something visible rather than behind a menu that has stopped responding. Two notes on what it deliberately does NOT do: - The load is still the ordinary blocking one. `ResourceLoader.load_threaded_request()` was the obvious way to get a real progress bar and it does not work here: asked for these scenes it comes back FAILED, with the text-scene parser reporting errors ("Parse Error ... Rock.tscn:9", "Could not resolve external class member PROFILES") that the same files do not produce through `load()`. The scripts and scenes reach each other through global class names and preloads, and that resolution is not available off the loading thread. A progress bar is not worth a menu that sometimes refuses to start the game - and the web build ships with thread support off anyway, so it could never have used that path. - So the bar is a sweep rather than a percentage. It reports "working", not "this far", because there is nothing honest to report. A second press while a load is running is ignored. On the web a button fires on PRESS (see IconButton), so an impatient double tap costs nothing to make and used to build the world twice. Covered in test_main_menu.gd: the cover is up and the menu is still the current scene immediately after the press, and further presses change nothing.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
metaheavens/spaceship#169
No description provided.