As the Faithful project expands and projects other than regular Faithful start using the database, using a single set of texture uses (and, by extension, paths) is less and less feasible. Each project follows a different texturing philosophy, so forcing everybody to use Faithful's use set is just impractical.
Let me explain: Faithful (Jappa), the project the current set of texture uses is tailored for, is very aggressive with texture backporting to older versions, meaning a single texture is often used in most or all of them. This simply isn't the case for Classic Faithful – and, in the future (most likely), Faithful Programmer Art – which is a lot more version-specific with textures. What projects like these need are their own, separate texture uses, which will allow them to utilise the database much more effectively.
What to do
My suggestion is to allow selecting projects for each texture use. This would be done via checkboxes when creating/editing the use, similar to how version selecting works when editing paths.
The projects I'm talking about are not identical to resource packs – resolutions don't matter in this case. That means using this list: Faithful, Faithful Programmer Art, Classic Faithful, Classic Faithful Programmer Art.
All existing uses should be assigned to all projects.
When searching in the gallery, the web app should only consider textures that are used in the relevant resource pack; For example when searching for Faithful 64x textures, textures that don't have Faithful set to true in any of their uses won't be displayed.
Additionally, when creating a new use, all projects should be enabled by default, as any edits are going to be global most of the time.
What this would accomplish
- Each project will be able to configure paths to its needs, allowing for more efficient autopush
- Textures will be able to be submitted to multiple projects at once, eliminating the need for duplicate submissions
- The database will be able to support more resource packs in the future, should the need arise
If we're gonna make the programmer art pack in the way I've got in mind (council approval pending), then implementing this is pretty much necessary before any work can be done.
As the Faithful project expands and projects other than regular Faithful start using the database, using a single set of texture uses (and, by extension, paths) is less and less feasible. Each project follows a different texturing philosophy, so forcing everybody to use Faithful's use set is just impractical.
Let me explain: Faithful (Jappa), the project the current set of texture uses is tailored for, is very aggressive with texture backporting to older versions, meaning a single texture is often used in most or all of them. This simply isn't the case for Classic Faithful – and, in the future (most likely), Faithful Programmer Art – which is a lot more version-specific with textures. What projects like these need are their own, separate texture uses, which will allow them to utilise the database much more effectively.
What to do
My suggestion is to allow selecting projects for each texture use. This would be done via checkboxes when creating/editing the use, similar to how version selecting works when editing paths.
The projects I'm talking about are not identical to resource packs – resolutions don't matter in this case. That means using this list: Faithful, Faithful Programmer Art, Classic Faithful, Classic Faithful Programmer Art.
All existing uses should be assigned to all projects.
When searching in the gallery, the web app should only consider textures that are used in the relevant resource pack; For example when searching for Faithful 64x textures, textures that don't have Faithful set to true in any of their uses won't be displayed.
Additionally, when creating a new use, all projects should be enabled by default, as any edits are going to be global most of the time.
What this would accomplish
If we're gonna make the programmer art pack in the way I've got in mind (council approval pending), then implementing this is pretty much necessary before any work can be done.