ThinKing_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()

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

        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?

          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.

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

              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 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?

                  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.

                    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.

                      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 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).

                          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.

                            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!!!"

                                ThinKing_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.