tl;dr writing a virtual resource pack API that allows mod to write and read virtual resources and register the pack.

Useful for a lot of stuff like LambdaBetterGrass' texture generation, and other similar stuff.

Would likely only expose low-level stuff.

note: this issue primarily exist so it can be referred to when anyone talk about this subject, plus to assign it to myself.

Imo the resource loader would also change to generate one single pack (presumably modifying the builtin minecraft pack) for all mod-required resources, data, etc. In the process of building that single pack, we will invoke other resource/data suppliers registered by mods.

But one problem in my logic is that some resources need merging, and merging is inconsistent. For tags it may merge, for loot tables or recipes, those are total replacements. Need to find a consistent way for those, or if we can tweak the reloadable resoruce manager to accomplish it.

One of the other goal that isn't noted anywhere is to remove the Fabric Mods resource pack and let mod resource packs be in the Default resource pack.

Resource pack merging logic already exists in Fabric API anyway.

@LambdAurora I don't think your group resource pack works correctly. Say you group multiple packs that add to the same tag without replacing. Only the highest priority tag file will actually be loaded, and this is definitely wrong.

It doesn't?

Please read the PR that introduced them.

It keeps the behavior of getResources intact by special casing group resource packs.

If this was broken the PR would never have been merged in the first place!

Hmm, I plan to hack resource pack profile's factory instead...

Here is a few problems I spotted in your original pr. #1186 (review) I personally ain't super fond of it (not as good as your recipe api before you added all those fancy stuff but better than the 1500-line updated recipe api)