Since our entire moderation system moved to Wynem well over a year ago, there's no reason to store these legacy warns anymore.

This would also allow us to make our raw user collection endpoints public since that's the only reason they're hidden currently.

Not sure what the best way to do this would be, I could probably write a quick parser that removes the warn fields from a given user, but if simply mapping the results would be easier do let me know.

Add short descriptions to add-ons which should have a limit of about 240 characters. Useful for embeds and some other things. The field should then also be added in the webapp.

Is your feature request related to a problem?

Users can't have their profile transferred if they switch accounts or for some reason no longer have the same discord ID.

Describe the feature you'd like

An endpoint that goes through and updates the addon, contribution, and user collection and basically find and replaces the old id with the new id

Screenshot(s)

interface could probably be the same as the path version changer:

PUT /users/modify/{old_id}/{new_id}

Notes

No response

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

• 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
• May not exist (so we don't have to edit every single path)
  • If this field doesn't exist, the regular versions field is used for display purposes
• Used for clarity in end user-facing UI (since all overlay paths are gonna be assigned to java-latest)

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

Is your feature request related to a problem?

Some textures are currently unsearchable in the DB, such as kz.png and up.png

Describe the feature you'd like

To prevent people being able to type "e" and get 721834719824718 results, simply force a non-partial search if the 3 character limit isn't met.

Screenshot(s)

No response

Notes

No response

(I am assuming this is an API problem, if it's a web app issue please let me know.)

Currently, the API always assumes that most paths in Java Edition start with assets/minecraft/ and tends to force-add this prefix to them in requests if they don't have it already. This more often than not leads to wrong image links, and really only creates issues.

Example:

Despite the path being correct in the database, the actual request looks like this:

The API should stop making any sorts of assumptions about the Java Edition paths and simply use them, unchanged, as they are in the database.
This would allow the web app and the bot to finally work with textures from 1.4.6 and b1.7.3, and probably some modded textures as well.
Resolving this issue would also allow us to make multi-version packs with the new overlay system introduced in 23w31a without any large changes to the existing database system, as textures intended to be used in overlays could simply have [overlay name]/ prefixed before their existing paths.

Is your feature request related to a problem?

Annoying to always remember to toggle to bedrock when searching on the gallery

Describe the feature you'd like

Add "all" option to gallery search endpoint to search all versions, much like texture tags

Screenshot(s)

Notes

No response

exactly what the title says, looks like the page hasn't been updated to match the main site in several months

Since the database zipped packs always have the same versioning scheme as the branch names, we can pretty easily do that with the same code that lets the texture URL code work.

Is your feature request related to a problem?

Merging textures is currently a bit of a pain and can be error-prone if the person doing the merging isn't careful.

Describe the feature you'd like

Add an endpoint that takes the uses and paths of one texture, applies them to another texture, and deletes the original texture.

Screenshot(s)

interface could probably similar to the path version changer:

PUT /textures/merge/{add_id}/{delete_id}

Notes

No response

The API currently use the npm run dev config; which is not intended in the production
As we need the API asap, it is running on dev for now, but we need to make it run only on a compiled version

• Replace the start process of pm2 to use npm run build && npm run start instead of npm run dev.

• npm start after build, show an error of missing module, need to be fixed.

• Another issue: if the files in ./build/ aren't compiled, the program builds them & it crashes, a restart needs to be implemented to avoid that on the first start, or just wait until to end of the build then restart/start.

When starting a search with settings version 1.19.2, gallery results (empty) were cached.
After updating minecraft version paths from 1.19 to 1.19.2, we restarted a new gallery search, but the previous empty results showed up.

What to do

Create new endpoints to erase cache values (all or with glob string parameter). The method to purge them all is even already coded, just some code for the glob one and endpoints and we it will be on. Just make a service and a controller.

I use fairly often the API page to watch the data type and values. However the number of sections has grown a lot since v2 start.

We could need:

• Some kind of menu or links to navigate would be appreciated
• A top arrow to go to the top of the page
• A descriptive footer like the documentation one

I was completing the rules for Add-on submission and added 14 links and not all of them were saved, which is a problem. I had 6 links, I then followed by adding one, and arrived with 5 of them.

Short notice, there seems to be a problem with link removal and save, check update method in service, with associated repository for more details.

This is quite urgent I must say

Textures can be divided following their basic attributes:

• A sprite : basic representation of a texture.
• An atlas : a composition of multiple sprites.

Which can be described like so:

  
export interface Tags {
  name: string;
}

export type FileExtension = 'png' | 'tga'
export type TextureName = string;
export type MinecraftVersion = string;
export type MinecraftEdition = 'java' | 'bedrock' | 'dungeons'
export type TextureType = 'atlas' | 'sprite' | 'tiled'
export type PackVariant = 'texture_pack' | 'resource_pack'

export interface TexturePath {
  /** Paths that leads to the texture */
  path: string,
  /** Minecraft versions where this path exist */
  versions?: MinecraftVersion[]
  /** File extension */
  extension: FileExtension;
}

export interface TextureUse<T extends PackVariant, E extends MinecraftEdition> {
  /** Minecraft game edition (java, bedrock, ...) */
  edition: E,
  /** Type of pack (texture_pack or resource_pack), useless for non-java edition games */
  type: T,
  /** Assets folder name for java edition files */
  assets: string, 

  // TODO: at least one of (atlas, paths) should be present in the object
  /** Atlas where you can find this texture inside */
  atlas?: {
    /** The corresponding atlas texture id */
    id: TextureName,
    /** Minecraft versions for which this texture is used in the atlas */
    versions: MinecraftVersion[]
  }[],
  /** Paths were you can find the texture for the given edition AND/OR versions */
  paths?: TexturePath[]
}

export type Position = { 
  /** Width start point (pixels) */
  x0: number, 
  /** Width end point (pixels) */
  x1: number, 
  /** Height start point (pixels) */
  y0: number, 
  /** Height end point (pixels) */
  y1: number
} | { 
  /** Column (starts at 0) */
  c: number,
  /** Row (starts at 0)*/
  r: number
} | { 
  /** Start Column (starts at 0) */
  c0: number,
  /** End Column (starts at 0) */
  c1: number,
  /** Start Row (starts at 0)*/
  r0: number,
  /** End Row (starts at 0)*/
  r1: number,
};

export interface TextureConfiguration {
  /** Textures uses */
  uses?: (
    // TODO: 'type' doesn't seems to be omitted when 'edition' === 'bedrock'
    | Omit<TextureUse<never, 'bedrock'>, 'assets' | 'type'> 
    | TextureUse<'resource_pack', 'java'> 
    | Omit<TextureUse<'texture_pack', 'java'>, 'assets'>
  )[],

  /** 
   * Texture atlas dimensions
   * - Use pixels (x,y) for uneven rows/columns (icons.png)
   * - Use columns & rows (c,r) for grids (terrain.png)
   * */
  size?: { 
    /** width in pixels */
    x: number, 
    /** height in pixels */
    y: number 
  } | { 
    /** number of columns */
    c: number, 
    /** number of rows */
    r: number
  }

  /**
   * Texture atlas map of contained textures
   */
  map?: {
    [id: string]: {
      /** Texture position within the Atlas */
      pos: Position
      /** For which version of the atlas the texture is set to this position */
      versions: MinecraftVersion[] | "all",
    }
  },

  /** Is the texture colored by the game? */
  tint?: boolean,

  /** Null if the texture is not animated, the mcmeta object otherwise */
  mcmeta?: null | object, 
}

export interface Texture<T extends TextureType> {
  /** Unique texture name identifier */
  id: TextureName;
  /** Aliases for that texture */
  alias: TextureName[] | null;
  /** What kind of texture it is */
  type: T;
  /** Short description */
  description?: string;
  /** Texture tags */
  tags: Tags[];
  /** In which pack this texture is used */
  packs: string[];
  /** Texture configuration, depends on the texture type */
  configuration: 
    T extends 'atlas' ? Required<Pick<TextureConfiguration, 'size' | 'map' | 'uses' >>
    : T extends 'sprite' ? Required<Pick<TextureConfiguration, 'tint' | 'mcmeta' | 'uses'>>
    : never
}

{
  "id": "grass_top",
  "alias": null,
  "type": "sprite",
  "tags": [
    { "name": "block" }, { "name": "tinted" }
  ],
  "packs": ["faithful"],
  "configuration": {
    "tint": true,
    "mcmeta": null,

    "uses": [
      {
        "edition": "java",
        "type": "texture_pack",
        "atlas": [
          { "id": "terrain", "versions": [ "b1.7.3", "1.0", "1.1", "1.2.5", "1.3.2", "1.4.6" ] }
        ],
        "paths": [
          { "path": "textures/blocks/grass_top", "extension": "png", "versions": [ "1.5.2" ] }
        ]
      },
      {
        "edition": "java",
        "type": "resource_pack",
        "assets": "minecraft",
        "paths": [
          { "path": "blocks/grass_top", "extension": "png", "versions": [ "1.6.4", "1.7.10", "1.8.9", "1.9.4", "1.10.2", "1.11.2", "1.12.2" ] },
          { "path": "block/grass_top", "extension": "png", "versions": [ "1.13.2", "1.14.4", "1.15.2", "1.16.5", "1.17.1", "1.18.2", "1.19.2", "1.20" ] }
        ]
      },
      {
        "edition": "bedrock",
        "paths": [
          { "path": "textures/blocks/grass_top", "extension": "png" }
        ]
      }
    ]
  }
}

{
  "id": "terrain",
  "alias": [],
  "type": "atlas",
  "description": "Atlas used for Minecraft version b1.7.3 until 1.5.2",
  "tags": [
    { "name": "atlas" }, { "name": "block" }, { "name": "item" }
  ],
  "packs": ["faithful"],
  "configuration": {
    "size": { "c": 16, "r": 16 },

    "uses": [
      {
        "edition": "java",
        "type": "texture_pack",
        "paths": [
          {
            "path": "terrain", "extension": "png",
            "versions": [ "b1.7.3", "1.0", "1.1", "1.2.5", "1.3.2", "1.4.6" ]
          }
        ]
      }
    ],
    "map": {
      "grass_top":            { "pos": { "c": 0, "r": 0 }},
      "emerald_block":        { "pos": { "c": 9, "r": 1 }, "versions": ["1.3.2", "1.4.6"]},
      "single_chest_bottom":  { "pos": { "c": 9, "r": 1 }, "versions": ["b1.7.3", "...", "1.2.5"] },
      "double_chest_front":   { "pos": { "c": 9, "r": 2 }, "versions": ["b1.7.3", "...", "1.2.5"], "size": { "c": 2, "r": 1 }}
    }
  }
}

This issue will list all the necessary steps to do before releasing the v3.0. It's mandatory since the v2 is currently sick of a mid-time remake that lacks direction, comprehension & reliability. The v3 is there to replace the v2 & definitely close the v1

• Switch from firestorm to MangoDB

  • Setup MangoDB server on the VPS

• Define new models for data:

  • Textures
  • Contributions
  • Changelogs
  • Posts
    • Addons
    • Website Posts
  • Mods
  • Modpacks
  • Users

• Migrate data

Currently, settings.json stores a bunch of information about various resource packs. I was thinking that consolidating all that stuff into a single packs collection would make a lot more sense, since it's already structured data with known keys (the submission pack interface is usable as-is, it's basically a collection within a collection as it stands).

Existing information that could be combined would include:

• Raw GitHub urls (for texture URL construction, autopush, finding MCMETAs, etc)
• Submission information
• Pack colors, display names, and logo URLs (currently stored in various settings.json fields)
• Pack resolution (for contribution interface, is this field even used anywhere?)

16x packs could be stored in addition to Faithful packs here by simply having a boolean flag to enable submissions for a given listed pack. This way, one could support an arbitrary number of packs simply by registering a new one in the packs collection and modifying a few TypeScript interfaces.

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 far as I can tell, only the Jekyll site currently uses the v1 API. As a result, there's no real reason to support it anymore given the site is to be replaced soon anyways. In addition, the only place that appears to use the raw Firestorm collections directly without the API is small parts of the webapp, which could pretty easily be replaced.

This would allow us to switch the raw json collections in the database to match the v2 formatting directly — currently the v2 API uses a bunch of mapping tools to switch formats on the fly. This would make backups easier too since what you write actually goes in as-is to the DB

yes

What happened?

When adding a header image, the API doesn't validate that it's a JPG before writing, leading to possible duplication of header images and incorrect paths.

To reproduce

1. Add a PNG-encoded header image to an add-on on the webapp.
2. Save.
3. Look at the corresponding folder on the DB for storing the header images.

Screenshot(s)

Notes

Would be ideal to fix the extension on the server end rather than forcing the user to do it.

Note: this is based off #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.

yes