|
| 1 | +from __future__ import annotations |
| 2 | + |
| 3 | +from typing import final |
| 4 | + |
| 5 | +from pydantic import Field, model_validator |
| 6 | + |
| 7 | +from minebase.types.base import MinecraftDataModel |
| 8 | + |
| 9 | + |
| 10 | +@final |
| 11 | +class ItemVariationData(MinecraftDataModel): |
| 12 | + """Minecraft-Data for an item variation. |
| 13 | +
|
| 14 | + Certain items have multiple variations that are distinguished through a metadata number. |
| 15 | + For example, coal (id 263) has a charcoal variation with metadata=1 (making it 263:1). |
| 16 | + These sub-items don't have their own entry in the items data, they're only tracked as |
| 17 | + variations of the parent item. |
| 18 | +
|
| 19 | + Attributes: |
| 20 | + metadata: |
| 21 | + The metadata number to distinguish this variation from the parent. |
| 22 | +
|
| 23 | + Each variation must have a metadata value. |
| 24 | + display_name: |
| 25 | + The item name as shown in the GUI. |
| 26 | +
|
| 27 | + Each variation must have it's own display name that differs from the parent item |
| 28 | + id: |
| 29 | + The unique identifier of the item. |
| 30 | +
|
| 31 | + Most variations don't have their own ID, and instead only contain metadata to |
| 32 | + distinguish them from the parent, however, some variations are given their own |
| 33 | + item ID, even though they're still only considered a variation of the parent. |
| 34 | + name: |
| 35 | + The minecraft name of an item (guaranteed to be unique). |
| 36 | +
|
| 37 | + Many variations aren't given a name and instead share the same item name with |
| 38 | + the parent item, and are distinguished only by metadata. However, some do have |
| 39 | + their own unique name, even though they're still only considered a variation |
| 40 | + of the parent. |
| 41 | + enchant_categories: Which enchant categories apply to this item variation |
| 42 | + stack_size: What is the stack size of this item variation |
| 43 | +
|
| 44 | + """ |
| 45 | + |
| 46 | + metadata: int = Field(ge=0) |
| 47 | + display_name: str |
| 48 | + enchant_categories: list[str] | None = None |
| 49 | + stack_size: int | None = Field(ge=0, default=None) |
| 50 | + id: int | None = Field(ge=0, default=None) |
| 51 | + name: str | None = None |
| 52 | + |
| 53 | + |
| 54 | +@final |
| 55 | +class ItemsData(MinecraftDataModel): |
| 56 | + """Minecraft-Data about an item. |
| 57 | +
|
| 58 | + Attributes: |
| 59 | + id: The unique identifier of the item |
| 60 | + name: The minecraft name of an item (guaranteed to be unique) |
| 61 | + display_name: The item name as shown in the GUI |
| 62 | + stack_size: The maximum amount that can be in a single stack for this item (usually 64) |
| 63 | + enchant_categories: Which enchant categories apply to this item |
| 64 | + repair_with: Items (item names) that this item can be combined with in an anvil for repair |
| 65 | + max_durability: The maximum amount of durability points for this item |
| 66 | + block_state_id: The unique identifier of the block that will be placed from this block item. |
| 67 | + variations: Variantions of this item (e.g. for coral, there's Tube Coral, Brain Coral, Bubble Coral, ...) |
| 68 | + metadata: Number used primarily to distinguish item variations (e.g. tall grass 150:1 vs fern 150:2) |
| 69 | + """ |
| 70 | + |
| 71 | + id: int = Field(ge=0) |
| 72 | + name: str |
| 73 | + display_name: str |
| 74 | + stack_size: int = Field(ge=0) |
| 75 | + enchant_categories: list[str] | None = None |
| 76 | + repair_with: list[str] | None = None |
| 77 | + max_durability: int | None = Field(ge=0, default=None) |
| 78 | + variations: list[ItemVariationData] | None = None |
| 79 | + block_state_id: int | None = Field(ge=0, default=None) |
| 80 | + metadata: int | None = Field(ge=0, default=None) |
| 81 | + |
| 82 | + @model_validator(mode="before") |
| 83 | + @classmethod |
| 84 | + def strip_durability(cls, data: dict[str, object]) -> dict[str, object]: |
| 85 | + """Remove the redundant `durability` field, if present. |
| 86 | +
|
| 87 | + The minecraft-data dataset includes both `max_durability` and `durability`, however, these fields |
| 88 | + always match, since this is the data for new items only. This makes the durability field entirely |
| 89 | + redundant; strip it. |
| 90 | +
|
| 91 | + This will get addressed with: https://github.com/PrismarineJS/minecraft-data/pull/1052 |
| 92 | + after which this method can be removed. |
| 93 | + """ |
| 94 | + if "durability" not in data: |
| 95 | + return data |
| 96 | + |
| 97 | + if "maxDurability" not in data: |
| 98 | + raise ValueError("Found durability field without max_durability") |
| 99 | + |
| 100 | + if data["durability"] != data["maxDurability"]: |
| 101 | + raise ValueError("The durability field doesn't match max_durability") |
| 102 | + |
| 103 | + del data["durability"] |
| 104 | + return data |
| 105 | + |
| 106 | + @model_validator(mode="before") |
| 107 | + @classmethod |
| 108 | + def rename_fixed_with(cls, data: dict[str, object]) -> dict[str, object]: |
| 109 | + """Rename the `fixed_with` field to `repair_with`. |
| 110 | +
|
| 111 | + These fields mean the same thing, however, the minecraft-data dataset includes one |
| 112 | + single version (bedrock 1.17.10), where for some reason, the field name `fixed_with` |
| 113 | + is used instead of `repair_with`. For a simpler user-facing API, this renames that |
| 114 | + field back to `repair_with`. |
| 115 | +
|
| 116 | + This will get addressed with: https://github.com/PrismarineJS/minecraft-data/pull/1052 |
| 117 | + after which this method can be removed. |
| 118 | + """ |
| 119 | + if "fixedWith" not in data: |
| 120 | + return data |
| 121 | + |
| 122 | + if "repairWith" in data: |
| 123 | + raise ValueError("Found item with both fixed_with and repair_with field") |
| 124 | + |
| 125 | + data["repairWith"] = data.pop("fixedWith") |
| 126 | + return data |
0 commit comments