Add pack information to cards #452

New issue

Closed

opened 2026-01-17 15:43:42 +00:00 by LunarTides · 1 comment

LunarTides commented

2026-01-17 15:43:42 +00:00

(Migrated from github.com)

This allows downloading cards directly instead of the entire pack it's in.

Benefits

Space

This saves space for the end users, but not that much really. Cards don't use much space (0.5 - 2kb for small cards, 3 - 10kb for big cards). But if we say that every card is 10kb (no currently implemented card is that big), and we implemented all 20k vanilla cards, that would be 200mb worth of data.

Smaller dependency footprint

Currently, if you want many different cards from many different packs, if those cards rely on cards from other packs, you can very quickly end up downloading a big chunk of the registry, especially if there is a big culture of reusing already existing cards instead of making your own versions. (Which should be encouraged.)

Downsides

Cards get bigger, more stuff for creators to think about, hard to implement, increases complexity. Fun stuff all around :)

Implementation

I'm thinking the implementation should look something like this:

// Added by the card creator library.
export const pack: PackInfo = {
    // Will be filled in by the packager.
    uuid: "",
    // Will be filled in by the packager.
    version: 0.0.0,
    wants: {
        // The uuids of the cards this card relies on.
        cards: [],
    },
}

export const blueprint: Blueprint = {
    // ...
}

The pack export needs to be required. If the uuid is empty, the card will be treated as not belonging to a

This makes it so that if you choose to download a card from the registry, it can download dependent cards, and put them in the new cards/downloaded folder as a "pseudo-pack". If a pack matching the uuid of the pack gets downloaded, the old card will be removed, since it's part of the new pack, unless the card has been changed (check using git), in which case, it should do something else. (Warn user / Abort.)

This is pretty complicated, but whatever. It should be possible.

This allows downloading cards directly instead of the entire pack it's in. ## Benefits ### Space This saves space for the end users, but not that much really. Cards don't use much space (0.5 - 2kb for small cards, 3 - 10kb for big cards). But if we say that *every* card is 10kb (no currently implemented card is that big), and we implemented *all* 20k vanilla cards, that would be 200mb worth of data. ### Smaller dependency footprint Currently, if you want many different cards from many different packs, if those cards rely on cards from other packs, you can very quickly end up downloading a big chunk of the registry, especially if there is a big culture of reusing already existing cards instead of making your own versions. (Which should be encouraged.) ## Downsides Cards get bigger, more stuff for creators to think about, hard to implement, increases complexity. Fun stuff all around :) ## Implementation I'm thinking the implementation should look something like this: ```ts // Added by the card creator library. export const pack: PackInfo = { // Will be filled in by the packager. uuid: "", // Will be filled in by the packager. version: 0.0.0, wants: { // The uuids of the cards this card relies on. cards: [], }, } export const blueprint: Blueprint = { // ... } ``` The `pack` export needs to be required. If the uuid is empty, the card will be treated as not belonging to a This makes it so that if you choose to download a card from the registry, it can download dependent cards, and put them in the new `cards/downloaded` folder as a "pseudo-pack". If a pack matching the uuid of the `pack` gets downloaded, the old card will be removed, since it's part of the new pack, unless the card has been changed (check using git), in which case, it should do something else. (Warn user / Abort.) This is pretty complicated, but whatever. It should be possible.

LunarTides commented

2026-02-12 20:32:38 +00:00

(Migrated from github.com)

Instead of including the pack in the card file, we can just read the associated pack.json5 metadata file.

- @Official
|  - builtin
|  |  - some-card-bcabababacacacba.ts
|  |  - pack.json5

The problem with this approach is obviously if a pack.json5 file isn't included.

Here's my reasoning on why I don't think that's a problem.
Custom cards generated by the card creator that don't belong to a pack yet is fine. They can be handled differently. I don't even need to check if the path includes Custom, I can just check if a metadata file isn't present.
Another concern is cards sourced from elsewhere that don't belong to a pack. But if a card doesn't belong to a pack, it won't get any benefits from this system, so whatever.

As long as I make sure a pack.json5 file is present by checking every parent directory (within the Hearthstone.js folder, of course), this should be fine.

Therefore, I don't think cards need to include this, so I'm closing the issue.

Instead of including the pack in the card file, we can just read the associated `pack.json5` metadata file. ``` - @Official | - builtin | | - some-card-bcabababacacacba.ts | | - pack.json5 ``` The problem with this approach is obviously if a `pack.json5` file isn't included. Here's my reasoning on why I don't think that's a problem. Custom cards generated by the card creator that don't belong to a pack yet is fine. They can be handled differently. I don't even need to check if the path includes `Custom`, I can just check if a metadata file isn't present. Another concern is cards sourced from elsewhere that don't belong to a pack. But if a card *doesn't* belong to a pack, it won't get any benefits from this system, so whatever. As long as I make sure a `pack.json5` file is present by checking every parent directory (within the Hearthstone.js folder, of course), this *should* be fine. Therefore, I don't think cards need to include this, so I'm closing the issue.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

LunarTides/Hearthstone.js#452

No description provided.

Rows
Columns