Autoload cannot be added in runtime

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

ALBATI_2005

As of the latest release of Godot Engine, there is no way to add an autoload during runtime, but it can only be added previously. Why?

There's a workaround, sure, by adding the scene as a child of the root, but it's tiresome to get it every time using get_tree().root.get_node("Autoload"), instead of simply writing Autoload.

Shouldn't such a feature be added into Godot 4, or is it already being added?

Edit: replaced $Autoload with Autoload, I just made a mistake writing it.

DaveTheCoder

ALBATI_2005 $Autoload

That syntax means the child "Autoload" of the current node. It would only make sense inside a script attached to the "/root" node, since autoloads are children of that node.
Is it possible to attach a script to "/root"? I've never tried that.

This might work in the script of your top level node (child of /root): $"../Autoload", assuming you have an autoload named "Autoload".

But you can access an autoload anywhere in the scene tree using only its name:
Autoload.some_property
Autoload.some_method()

cybereality

I've never tried this. Can I ask what you need this feature for?

ALBATI_2005

cybereality Well, if I want to have a "preload_global" autoload where I store global resources, it will take lots of time to be loaded, which means the game will be stuck on the splash screen for some time. Hence, I will be forced to load this autoload AFTER the splash screen (in a nicer_looking loading screen for example, or a sequence of showing companies involved, etc.). As this is the case, I will have to manually add the autoload in a workaround and call it later on with a long a line of code. (There is also the fact that custom splash screens do not scale correctly on Android devices for some reason, so I try to avoid them altogether by making them a black screen, but I guess that's another problem altogether).
Also, having more options at hand generally gives better freedom to the developer, so I think it would be a nice feature overall.

ALBATI_2005

DaveTheCoder Sorry, I made a mistake. Just forget about that dollar sign, and read the paragraph again, it should make sense that way.

DaveTheCoder

Okay.

But what do you mean by "there is no way to add an autoload during runtime"?

Are you asking about referencing the autoload, or creating it?

ALBATI_2005

DaveTheCoder creating it.

DaveTheCoder

What about creating the autoload in the normal way (Project Settings), and populating it at runtime?

ALBATI_2005

DaveTheCoder OK, so I did exactly as you suggested and kept the structure of "preload_global autoload". Not only did it make my code cleaner to use the Autoload from the Engine (in Project Settings), but also, SOMEHOW, released TONS of RAM. You know I've been struggling with that for a while, despite my fairly simple game, so that was a big magical moment for me.

I think this gives me a better idea why Autoloads can only be loaded in the beginning. Maybe they're "hardwired" into the code that adding them during runtime will take up much more memory... I don't exactly know, but that RAM free-up was absolutely NOT normal. I guess being antipattern isn't good in programming, especially when going against philosophies on which the whole Engine and programming language are built upon.

Oh, I forgot to "thank you very much!!!"

ALBATI_2005

DaveTheCoder That's a good idea, if for example I assign some script to it during runtime with variables and all. I never tried it before, but it's still a workaround, and maybe a bit complicated to basically create an autoload during runtime. I think, for the sake of accessibility, it is easier to have it as an already present function. Though your solution (if it works, haven't tried it yet) does actually solve my nitpicking of having to write long lines of code, so thanks!

cybereality

In that case it might be a good idea to have the autoload only have references and basic functionality (functions, etc.) and then load the actual resources as they are needed, or just before (as in a loading screen between levels). You can also look into background loading, but it's more advanced.

https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html

ALBATI_2005

cybereality I guess that solves my problem, though I'm still wondering why is it not possible to do what I suggested... is there some kind of limitation, or was it simply never needed?

DaveTheCoder

Personally I don't see the need for that feature. But you could submit it as a proposal, and get feedback on it.
https://github.com/godotengine/godot-proposals

ALBATI_2005

DaveTheCoder Thanks for the link!

JoelRummel

The main purpose of autoload is to emulate the singleton pattern. Anything that's autoloaded is essentially guaranteed to be permanently available and globally accessible from any other script.

An autoload-at-runtime feature would be in violation of these design philosophies, and any problem solved by it would probably be considered an antipattern. As mentioned further up in this thread, you don't need to immediately load all of your global resources via autoload - you can load them at runtime to prevent hanging on a splash screen.

ALBATI_2005

JoelRummel I see, so it's philosophy... To be honest, the only reason I went for the "preload_global" autoload approach was to avoid 'loading a resource twice', but since I learned that such a thing won't happen in Godot, I have nothing to worry about, so I guess I can simply leave that approach behind and stop being antipattern

Edit: by learned, I mean here: https://godotforums.org/d/30623-does-instancing-the-same-object-several-times-increase-ram-usage

cybereality

Also, not sure about Android, but on desktop you can make a loading scene that looks identical to the splash screen (except maybe including a loading bar or some animation). This is what I have done in the past, and it's an acceptable solution. If you look at most AAA games, this is what they do as well.

ALBATI_2005

cybereality I thought about that previously, but there is some problem with custom splash screen fitting the whole screen on Android... I think I should rather report this issue on github. I once saw people discussing this issue on Reddit, but never found a solution (except one that went really deep into coding using android studio).

cybereality

Yes, Google changed the way splash screens work on Android about 2 years ago. The solution is to have the splash just been a smaller logo (such as a logo of the game or the company against a black background) and then the main scene is the loading scene, which can have more detailed graphics and a loading bar animation, etc.

ALBATI_2005

cybereality That's actually a very smart solution! Thank you, I'll keep that in mind.

Megalomaniak

ALBATI_2005 but also, SOMEHOW, released TONS of RAM.

Well yeah, the globals/autoload is loaded at the very start of the application and only released when application quits.