Modular Resources

[gusxyz]

Motivation for this Pull Request

Currently, downstreams are forced to mix their custom assets into the monolithic Resources/ directory. To keep files organized, resorting to what I will dub the "Underscore Hack"--prefixing folders with _ (e.g., _Goobstation, _Corvax) just to group files together.

The Results:
Features are split across multiple of Resources/ "root" directories instead of being contained in a single module, which is less than ideal to maintain.

The Solution:
This PR introduces Modular Resource Loading. It allows a fork to mount entirely separate physical directories (e.g., ModResources/) alongside the standard Resources/ folder. The engine treats these as native VFS roots without forcing them to live inside the standard directory structure.

Tested

• Regular resources folder still loads correctly (Backward compatibility).
• Modular textures and rsis load via SpriteComponent.
• Verified maps load from modular directories.
• Verified packaging release builds preserve the folder structure and run without crashing.
• Verified Hot Reloading detects changes in modular folders.
• MacOS and Linux working

Technical Analysis

This may not have been implemented in the best way so any suggestions are very welcome.

[gusxyz]

Drafted until test fails fixed.

[alexalexmax]

holy peak

[gusxyz]

Realized test fails are not related.

[deltanedas]

how does it treat e.g. Modules/Goob/Resources/door.rsi and Resources/door.rsi
does it override the core sprite?
does it have a stroke?
what happens if multiple resource dirs do this?

[mirrorcult]

from devbus but posting here for posterity, this seems like an overly complicated solution

you'd still have to change stuff that specifically iterates a subdir (prototypes) or assumes some prefixed directory automatically, but this shouldnt need packaging or creating multiple roots

[PJB3005]

You're really going to have to justify why downstreams can't do the far simpler solution of having top-level folders inside Resources, as others have pointed out.

[gusxyz]

You're really going to have to justify why downstreams can't do the far simpler solution of having top-level folders inside Resources, as others have pointed out.

Yeah your totally right, downstreams could just use Resources/ForkNames, but that would still require roughly 90% of this pull request as of how SpriteSystem and AudioSystem still hardcode prefixes of /Textures/ and /Audio/ respectively.
The manifest resource loading related code is only about 37 LOC.
At that point I believe its best to give downstream the decision with where to place their own resources folder.
I personally believe that allowing loading multiple resource "packs" is a very common practice in modern game engine design, the monolithic resources folder harkens back to the BYOND days.

For example if it is chosen to keep the manifest loading section of this pr:
A downstream could choose to put there resources folder inside of Modules/ForkName/Resources along side the rest of the c# projects (e.g. Modules/ForkName/Content.ForkName.Shared) to isolate there fork completely.

I am totally willing to continue this discussion, as I have a lot more thoughts!
Or I can pivot this pull request to just support more roots inside of Resources if that is what is believed to be best for the engine, I personally believe giving downstreams more flexibility is the best way to go.

[PJB3005]

I personally believe that allowing loading multiple resource "packs" is a very common practice in modern game engine design, the monolithic resources folder harkens back to the BYOND days.

This is both incorrect and misunderstanding how modern game engines actually work.

This is not up for debate. We aren't having this feature. One resources folder.

[PJB3005]

My dearest esteemed chuds how do I ship my resources for my Content.Shitfuck.Client module

This is a formal warning that these kinds of comments are not welcome in our community. Be productive.