That's why I hereby plead to merge this addon in the Engine natively. (i.e. to reopen godotengine/godot-proposals#10051)

First off, I really appreciate that others are seeing my Resource Remaps implementation to be helpful and necessary!

Secondly, I'm curious if it might be possible to promote my plugin to be an official plugin and/or link to it directly from official docs, etc.? The benefit to this would be to allow the plugin to get some real-world use before being implemented "permanently" into core. The obvious downsides are needing to keep the plugin in your project source files and needing to install it to all projects.

That said, I would be very happy to help test a native port of this plugin! I wrote the scripts to be easy to do a 1:1 port into C++ code of the editor.

I'm indifferent about whether the plugin should be linked to, promoted to official, or integrated into core -- I just figured it would be good to mention some options that exist. We can maybe open a different proposal to discuss the options...

I know it's bad form to use this as a place for compliments, but...

This is FANTASTIC. I've fought with web load times for more hours than I care to admit, and I'm thrilled to see the problem being wrestled with from within Godot now!

Thanks all!

Async background loading is a super-desirable feature for web exports. In combination with an out-of-the-box brotli compression system, this could be a major step to get more Godot games shipped on the web.

We are installing files, now?

"Install" is the most appropriate word I could find to describe this process, as "load" is already a term users actually use in their projects to load assets in their game.

In the context of AsyncPCKs, "installing" means to make the file available to "load". For the Web platform, it implies downloading the file first.

This could be referred to as "registering". I think "installing" implies a filesystem operation that causes I/O to happen on disk (like the UNIX install command), while "registering" doesn't.

Or maybe "acquire", "obtain", or "attain". Acquire may be my preferred "load"/"download" alternative.

Edit: I guess AsyncPCKAquirer is super awkward, though. So maybe AsyncPCKObtainer, AsyncPCKAttainer, or AsyncPCKFetcher

I think I like AsyncPCKFetcher the most...

We just discussed this PR (or rather its ideas and API design) in the core meeting.

Here are the meeting notes (by request of adam) for quick online reference.

If I may attempt a summary: The feature seems unquestionably useful, including the provided API. However, attendants raised that most users will likely not use this API, and therefore it would be nice to also integrate async loading into existing APIs made for async loading (as well as possible), and provide users with warnings about improving load times further.
In addition, there was some disagreement about whether misusing the async API on platforms without async pck implementations should perform the requests as expected, or error out (for consistency to web).

Allen: Which tools will we provide to work with / understand / debug async loading?

- Allen: For example, a tool that blocks loading as if you had a very slow internet connection

Holon: Suggested falling back to installing a file automatically if there is a load request, to make it easier to adopt this / not need to develop specifically for it

- e.g. ResourceLoader::load_threaded_request, ResourceLoader::load_threaded_get_status , ResourceLoader::load_threaded_get
  - Adam: This API is not available in single-threaded web games (which are most web games)

Holon: Voiced concerns about existing async resource loading APIs

- Adam: Most godot web games are single threaded, PR defers downloading to browser to make use of this 'multithreading'
- Holon: Freezing as a fallback would be fine worst case (games adopting this explicitly would of course deal with it better)
- Clay: The API should integrate with existing methods and synergize with it
  - For example, if somebody is already async loading, we can async load the pck (even in single-threaded web), and then sync-load into RAM
- Holon: The current async pck node is a power user implementation, normal users won't make much use of it
  - Integrate async loading with existing methods (e.g. threaded load functions, which in single threaded mode won't actually use threads but async functions)
    - ... But also offer the 'power user' option for those that want to squeeze out even better load times
- Adam: Integrating into existing APIs is interesting, but have concerns about mixing unrelated techniques
  - Would prefer to keep the API isolated for users that need it, but not integrate it

Allenwp: How to handle loading screens?

- Ivorius: Would be nice if it was really easy to do this, as a 'low effort' integration option

Clay: A silo'd off solution would not be adopted, async pcks should integrate strongly with Godot

- Adam: Disagree that it's silo'd off, users would just need to commit to the 'async workflow'
- Clay: Suggest the engine kicking off download automatically, and only start the actual load when it's done downloading

Clay: Pointed out similarity to downloading from GPU, where calling some APIs can stall the game

- These APIs return the result as expected, but print a warning to point the user to better APIs
  - Important point is, it works, just not perfectly. 
  - Adam: Would prefer to error out and not return the expected result
    - Clay: In this case, we would add a footgun where you make a game that works in the editor, but fails in web
    - Clay: Re-discuss some other time

Clay: When trying to load an async pck resource that is not 'installed' / downloaded yet, we should at minimum show an error like "the resource is part of an unloaded async pck"

- This should be in all platforms, not just web
- Otherwise, users will complain about 'bugs' in the engine / not understand why web isn't working as expected
- Adam: There are no async pcks for desktop
  - Clay: It should be the same anyway, just reject the load on desktop if not loaded explicitly
  - Adam: People should just use AsyncPck Node, then it 'just works'
- cerberus: People will spend most time testing locally on their platform, and only export to web at the end
  - Worried that games will break last minute when testing in web

I agree that loading a resource should install it automatically if not installed already (can print a warning or something, to inform the user). Also not sure why async loading needs a node. Like, you need 2 methods to handle installing (downloading) assets: is_installed() and install() (and maybe get_install_progress() to get progress). They can be in ResourceLoader and is_installed() would always return true in non-web platforms.

You didn't mention this, but in the meeting there was also an idea to rename load_threaded_request() to load_async_request(), to better convey that it's a generic async loading method, if we change it to automatically handle installing. If an asset is not yet installed, the "threaded" loading will simply take longer and require no changes to the code. The new install-related methods would optionally allow to better strategize when to install something.

As for debugging tools, the editor is able to start a server to host web build locally, no? Maybe it could be extended to allow simulating slow download times?

Quick amendment to my comment from the meeting: not only do slow downloads need to be testable by the game developer, but also unstable connections or connection drops. For example, if you enter a tunnel on a train and loose your internet connection entirely for a period of time. Some games may want to handle this gracefully or automatically via this feature's APIs.

Commenting here, because I can't get the other PR to build on my end, but probably the same issue applies:

I tested whether this PR reintroduces #91726 and indeed when initially importing the linked project I get error spam.

• the errors are different than in the old issue, so maybe it's not GDScript related. Hard to say with such a big PR
• the error spam does not occur after the initial import
• there is no error spam in the project on master and 4.6