[FEATURE] Make texture uses project-specific

[Pomi108]

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.

[RobertRR11]

(Yes, very timely reply) This would very likely need a restructuring of the database so it's unlikely to be done anytime soon.

[Pomi108]

The thing is, it's needed pretty soon. Programmer art is just around the corner

[Juknum]

Well, I guess it might be possible to make some modifications that won't break many things:

• This is what we currently have:

• And this is what we could possibly do:

  Here you can see that the texture object has a new field packs which is an array of packs ids, allowing packs with similar texture>uses>paths combination to be grouped together like Faithful "Jappa" x32 & x64, or like Faithful "Prog. Art" x32 & x64.

PSA: The 1 -> * means 'One to many' where there is one texture with multiple contributions/uses (same goes for uses>paths)

[TheRolfFR]

Well I agree with @Juknum, this is how I see things: A project has textures, sure textures can be in different packs. One texture can be used to multiple places, for different purposes, and has differences depending the edition, and then you have paths depending the minecraft versions.

Maybe use a codename for projects and have a display name (avoid rebranding issues like, for example, Faithful -> Compliance -> Faithful)

[3vorp]

Alright, so I've come up with a system that does this but even better:

interface PackSpecificUse {
    id: number; // this would be a texture id
    join: FaithfulPack[][];
    omit: Record<UseID, FaithfulPack[]>;
}

Now, I'll break down what this actually means.

This would be an entire separate JSON, much like how contributions.json is separate from all the texture ones. It would use texture ids as the property keys, rather than the use IDs Pomi originally proposed, because this would also let you join together multiple packs' contributions.

The join field, appropriately named, would merge multiple the textures of multiple packs together, so a submission or contribution to one texture would count as a submission and contribution to the other. This would be formatted as a two-dimensional tuple, with the nested one serving as the packs to join, and the outer one serving as a way to let multiple packs join together without interfering with each other.

Some sample data for that could look like:

"join": [
        ["classic_faithful_32x", "classic_faithful_32x_progart"],
        ["faithful_32x", "faithful_32x_progart"]
]

As you can see, the Classic Faithful packs are merged together, and the Faithful packs are merged together, but the Classic Faithful and Faithful packs are not merged together. That's what the extra dimension is there to do. In addition, this is a lot more flexible than the proposed rigid set of packs that could be joined — if someone really wanted to, they could merge Faithful 32x and Faithful 64x textures, or even merge Classic Faithful and Faithful textures for stuff like the font, which is the same between both.

This also lets you do a clever thing, which is directly merge contributions. By slightly modifying the contribution interface to take an array of packs rather than a single one, a single contribution could be "subscribed" to multiple packs, and each pack would show that contribution rather than duplicate ones. You could easily run through the join list for a given texture after a submission has passed, and if the submitted pack matches any of the joined tuples, you could apply the contribution to all those packs and push to all of them, since now the database says they're one and the same. While this would technically be a breaking change, it's nothing that couldn't be dealt with reasonably easily.

Finally, you could even create "readonly submissions", where if a texture is submitted to one project and is merged in another project, it would duplicate the submission message with a note to tell you to vote in the submitted project's respective submission channel so they could transparently see what's getting changed too.

Here's a quick preview I made of what that could possibly look like, although obviously not finalized.

---

Now, for the omit field. This is a dictionary, with an arbitrary number of unordered keys being use IDs, and their corresponding keys being an array of Faithful pack IDs. Essentially, each use would let you "omit" a pack or multiple packs from using that use. For instance, Faithful doesn't have a separate set of textures for the pre-1.12 wools, so you could easily omit the programmer art packs from the 1.11- use, and add a new set of textures that everything else is omitted from and is just for 1.11 wools.

Some sample data for that could look like:

"omit": {
        "307b": ["classic_faithful_32x_progart"],
        "307a": ["faithful_32x", "faithful_64x"]
}

Now, this might sound like it makes the pack less pack-agnostic. The whole point of the Faithful texture database is that anyone can use it without too much difficulty, but the important thing to consider is this entire use system is an overlay on top of the existing system. If you were to include all uses, with no omissions, you would still have a very usable experience since by default, all uses are enabled. That's what makes the omission system so much better than an "include" system, which would require one to opt in packs to every new created use. Even if the separate 1.11 wool textures were enabled, which you didn't need, you could simply ignore them entirely, since they're not uses in an existing texture but optional extras to ensure proper compatibility. If someone was to fork the submission bot and run it on their own, it would still work right out the box since it would essentially enable all uses for all textures, and not merge anything.

[TheRolfFR]

I must say this structure isn't good. I don't think we need texture specific join if they are always the same and omit uses in packs, start to make no sense at all. You may find the "include" system very heavy with the "opt in" system but it makes sense because you can really see what is in each pack. Your proposition is gonna be a brainfuck trying to understand what's included where.

I erased a lot of lines trying to write this comment and it is already killing my mind.

Maybe using a real world pack example would help identifying the data and how they are linked: For X pack, we use textures from Y pack for version A to B and textures from Z pack for version A to B, maybe, I don't know.

What is sure is that textures are related to their existence in the 16x version through space and time. (x,y,z,t) We can say without a dubt that the look of this texture (quote "Faithful Programmer Art – which is a lot more version-specific with textures") existed at some point in one minecraft version (or more) (this is time) at specific paths (this is space) throughout different editions (this is space too but other dimensions).

So now, we can define that a pack for a version is fixed moment in time with the style you want for this texture to look like.

Maybe this should be the base of the new existence of textures and that we make contributions not into packs and texture, but to this "pin-point":

It's the fucking multiverse of textures. (not easy, right?)

[Pomi108]

What?

[3vorp]

I sorta see what you mean, but the main idea of having project-specific omissions and joins is that it can simply serve as an overlay on top of the existing system. There's far fewer breaking changes, and you can still use the texture database without being a registered resource pack (either by simply ignoring the pack field, or using the uses from an existing pack).

If we were to completely break compatibility with the current system (such as Juk's proposed API v3), I do think something like what you're talking about may be interesting to consider, but for the time being I don't want to unnecessarily rewrite large portions of things that already work fine — this system ensures the fewest random exceptions and has the fewest breaking changes.

[3vorp]

Also chances are, since there's so many breaking changes, I'll probably wait for the website rewrite to fully implement this — the submission pack API can come first and that will lay out a better infrastructure for this too.