search

Faithful-Resource-Pack / API

A public API for Faithful Resource Pack textures, add-ons and more
https://api.faithfulpack.net
GNU Affero General Public License v3.0
0 stars 0 forks source link

Preparation for Overlay compatibility #30

Closed Pomi108 closed 9 months ago

Pomi108 commented 1 year ago

This issue goes in tandem with App#110, Discord-Bot#249, and Database#4

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.

Dealing with Default Textures

When fetching default (16x) Java textures that are only assigned to version java-latest, the API should only return their vanilla path, stripped of the overlay prefix. (e.g. 1.20.2/assets/minecraft/textures/item/apple.png from the database would be returned as assets/minecraft/textures/item/apple.png) This is necessary so the gallery/bot don't break with vanilla textures, but the bot is still able to push to the correct paths within the overlay directories.

Display Versions

The API should be updated to work with display versions the same way it currently works with regular versions.

3vorp commented 12 months ago
  • 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

Can't we just reuse the versions field if it's the same?

Pomi108 commented 12 months ago

It's not gonna be the same for all textures, that's the point. Internally, all new textures will be assigned and pushed tojava-latest (because of the overlays), but to keep things clear for end users this field serves the purpose of displaying what versions the texture is present in vanilla

3vorp commented 12 months ago

But isn't the new system only present in java-latest+? How would it make sense to push all versions to it if it only works in new versions?

From what I know, it seems like supporting multiple versions at once will only work for versions 1.20.2 and up, meaning we can just filter for the version number on the bot end? Please correct me if I'm wrong.

Pomi108 commented 12 months ago

But it isn't gonna be applied to all versions – that's why I specified that the field may not exist. Yes we could filter the version on the bot/app/whatever side, but my solution ensures that 1) it's universal and 2) end users will be able to see the actual versions the texture is present in.

Pomi108 commented 12 months ago

If I'm missing something please tell me, I'm not sure I entirely understand what you're suggesting

3vorp commented 12 months ago

The main thing is I really don't want to have to edit the database itself because the database itself really needs updating to the modern format — internally, everything is stored using the original API v1 format still and is being mapped to the current format. Once everything that relies on the actual database is removed, this would probably be easier to implement.

My alternate idea for the time being would be that java-latest basically doesn't exist to the API, and instead you append a java-latest to the path being pushed and fetched if the version is greater than 1.20.2 (the "latest" feature in the URL would always redirect to java-latest). This would also make it easier to change the overlay features later since you wouldn't have breaking changes with the API.

For instance: https://raw.githubusercontent.com/faithful-resource-pack/faithful-java-32x/1.20.2/assets/minecraft/textures/block/dirt.png would be transformed as https://raw.githubusercontent.com/faithful-resource-pack/faithful-java-32x/java-latest/1.20.2/assets/minecraft/textures/block/dirt.png.

This feels much less invasive than the proposed changes and from what I can tell should accomplish much of the same features needed. Please let me know if I'm completely misunderstanding everything.

Pomi108 commented 12 months ago

As long as the solution allows me to edit what versions are displayed to the end user while still pushing to java-latest, i don't really care how it's implemented. Display versions are just one way to go about it.

3vorp commented 9 months ago

update: since all the texture jsons have been updated to v2 adding new fields is a lot easier now

3vorp commented 9 months ago

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: