[Feature] Preparation for Overlay Compatibility

[Pomi108]

This issue goes in tandem with CompliBot#249, Database#4, and API#30

Since 23w31a Minecraft allows resource packs to work with multiple pack formats at once. Overlays are a way for packs to provide files that need to be changed for them to work with a specific pack format without overwriting the base files of the pack. (More info in the linked minecraft.net article.)

While our software is technically mostly compatible with overlays aready, I am proposing some changes that, if implemented, would make the experience friendlier to end users and ensure nothing breaks in the future.

Path Truncating

Affects: Gallery texture menu

Overlay paths (i.e. Java paths only in version java-latest that don't start with assets/) should have their paths trimmed in the gallery texture menu to remove the overlay prefix (1.21/ for example) so that only the vanilla path starting with assets/ is visible to the end user. This should not be the case for admin tools! The full paths need to be visible there.

Display Versions

Affects: Gallery texture menu, texture creation modal, path edit modal

• A new field for paths in the database
• Identical to the existing versions field in every way, except it doesn't set the repo branches to push textures to
• May not exist (so we don't have to edit every single path)
  • If this field doesn't exist, the regular versions field is used for display purposes
• Used for clarity in end user-facing UI (since all overlay paths are gonna be assigned to java-latest)

The existing menus and editors in the web app should be modified to allow for display version editing, and show display versions instead of regular versions where appropriate. java-latest should also be made the default version for Java paths in the texture creation modal, as the vast majority of future new textures will be assigned to this version internally.

[3vorp]

After months of discussion, many, many potential solutions, and a lot of thought for edge cases, we've decided not to implement overlays into Faithful.

The main reasons include:

• Default and Faithful packs would have to be treated completely differently.
• Dots aren't allowed in overlay folder names, making overlay versions impossible either way.
• /missing as a concept would completely break.
• Branches and versions will no longer be synonymous, an assumption many things rely on.
• No good way of thresholding between real and display versions.
• java-latest would both exist and not exist at the same time in a really confusing state.