Poradniki / Budowanie i zasoby
Paczka skórek do Bedrock to cztery pliki, a dwa jej tryby awarii są ciche
Dwa UUID-y, które muszą się różnić, plik lang, który nie jest opcjonalny, oraz klucze skórek usuwające znaki interpunkcyjne — więc „My Skin!" i „My Skin?" stają się jedną skórką bez żadnego błędu.
Paczka skórek do .mcpack to zip z innym rozszerzeniem, a znajdująca się w nim paczka skórek wymaga dokładnie czterech rodzajów plików:
manifest.json a header and a skin_pack module, each with its own UUID
skins.json one entry per skin: texture, geometry, and a KEY
texts/en_US.lang the display names — skins.json holds only keys
*.png the textures themselves
Trzy z czterech łatwo zrobić poprawnie. Ciekawe awarie wynikają wyłącznie z relacji między nimi.
Dwa UUID-y muszą się różnić
manifest.json zawiera UUID w swoim header oraz drugi w module skin_pack:
{
"format_version": 1,
"header": { "name": "…", "uuid": "…", "version": [1, 0, 0] },
"modules": [ { "type": "skin_pack", "uuid": "…", "version": [1, 0, 0] } ]
}
To dwie odrębne tożsamości — paczka i to, co jest w środku paczki — a użycie tej samej wartości dla obu jest prawdziwym błędem, mimo że nic nie protestuje w czasie budowania.
Jest jeszcze drugi, subtelniejszy skutek: ponowny import z tymi samymi UUID-ami jest traktowany jako ta sama paczka, a Minecraft po cichu zachowuje kopię, którą już ma. Edytowanie paczki, przebudowanie jej z tymi samymi identyfikatorami i ponowny import wygląda, jakby nic nie zrobiły. Każda kompilacja z tej strony dostaje świeże UUID-y właśnie z tego powodu, dlatego też ponowny import edytowanej paczki wymaga świeżego pobrania, a nie ponownego spakowania starej.
Plik lang nie jest opcjonalny
skins.json nigdy nie zawiera nazwy wyświetlanej. Zawiera klucz, a texts/en_US.lang mapuje ten klucz na tekst:
skinpack.<PackKey>=My Pack
skin.<PackKey>.<SkinKey>=My First Skin
Wyślij paczkę bez pliku lang, a nic nie zgłosi błędu — każda skórka po prostu pojawi się w grze pod swoim surowym kluczem. To najczęstszy powód, dla którego ręcznie złożona paczka wygląda na zepsutą, choć przechodzi walidację bez problemu.
Klucze usuwają znaki interpunkcyjne, a duplikaty się zlewają
Klucz musi być alfanumeryczny. Wszystko inne jest usuwane:
| twoja nazwa | klucz |
|---|---|
My Skin! | MySkin |
My Skin? | MySkin |
Skin #2 | Skin2 |
!!! | Skin1 (zapasowy, według pozycji) |
Pierwsze dwa wiersze to pułapka. Dwie skórki nazwane po ludzku w sposób rozróżnialny stają się jednym kluczem, a zduplikowany klucz nie zgłasza błędu — po cichu zlewa się w jedną skórkę w grze. Wgrywasz dwanaście skórek, dostajesz jedenaście i nic nie mówi ci, która zniknęła.
Budowniczy z tej strony broni się przed tym, dopisując licznik do każdego klucza, którego już użył, więc drugi MySkin staje się MySkin2. Warto o tym wiedzieć, jeśli składasz paczkę ręcznie: sprawdzenie, którego potrzebujesz, dotyczy nazw po usunięciu znaków, a nie tych, które wpisałeś.
Nazwa złożona wyłącznie ze znaków interpunkcyjnych nie zostawia niczego, więc spada do Skin plus swojej pozycji na liście.
Slim wymaga właściwego ciągu geometrii
Każdy wpis wskazuje model, a są dwa:
geometry.humanoid.custom— klasyczny, ramiona o szerokości 4 pikseligeometry.humanoid.customSlim— slim, ramiona o szerokości 3 pikseli
Pomyłka tutaj to zwykła przyczyna tego, że skórka o proporcjach Alex pojawia się z kanciastymi ramionami Steve'a. Tekstura jest w porządku; to model jest tym, o który się prosi. Budowniczy paczek zgaduje go na podstawie dwóch kolumn, które zostawia puste ramię slim (x 54–55), i pozwala ci to poprawić dla każdego wpisu, ale ręcznie napisany skins.json musi to powiedzieć wprost, a oba ciągi różnią się o cztery znaki na końcu.
Wpisy zawierają też "type": "free", a peleryna to opcjonalny dodatkowy PNG przywoływany z tego samego wpisu — peleryna podróżuje wewnątrz paczki skórek, a nie jako osobne pobranie.