A robust system for project-specific textures need two levels to work — a "join" field, and an "omit" field.
The "join" field would be a two-dimensional array of pack IDs to join together on the texture level. Each inner array would be a series of packs to join the contributions and autopush of.
The "omit" field would work on the use level as an additional field where an array of pack IDs would be specified. These packs would be omitted from the use and not be applied during autopush or searching for textures.
To make this work with the current API, almost nothing will really need to be changed other than the texture creation and modification endpoints. Existing client code will have to adapt to this instead — autopush can use the join and omit system in choosing what to push where, and the fields will have to be added to the web app texture modals. I'm not going into my previous issue comment on how the "subscription" system works, but this is designed to have the minimal number of breaking changes.
Note: this is based off https://github.com/Faithful-Resource-Pack/API/issues/40, so I'm not gonna re-explain the rationale or logic here, but rather only the stuff to actually do.
A robust system for project-specific textures need two levels to work — a "join" field, and an "omit" field.
The "join" field would be a two-dimensional array of pack IDs to join together on the texture level. Each inner array would be a series of packs to join the contributions and autopush of.
The "omit" field would work on the use level as an additional field where an array of pack IDs would be specified. These packs would be omitted from the use and not be applied during autopush or searching for textures.
To make this work with the current API, almost nothing will really need to be changed other than the texture creation and modification endpoints. Existing client code will have to adapt to this instead — autopush can use the join and omit system in choosing what to push where, and the fields will have to be added to the web app texture modals. I'm not going into my previous issue comment on how the "subscription" system works, but this is designed to have the minimal number of breaking changes.