Skip to content

[Long-term] Project-specific textures #39

Description

@3vorp

Note: this is based on #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.
Screen Shot 2024-01-08 at 8 44 36 PM

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.
Screen Shot 2024-01-08 at 8 42 57 PM

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions