diff --git a/wiki/misc/mappings/ua.md b/wiki/misc/mappings/ua.md new file mode 100644 index 0000000..3e7f37e --- /dev/null +++ b/wiki/misc/mappings/ua.md @@ -0,0 +1,62 @@ +## Налаштування маппінгів у вашому середовищі розробки + +### Що таке маппінги? + +Перед тим як нова версія Minecraft потрапляє на сервери Mojang, вона проходить процес, що називається _обфускацією_, коли імена класів, полів і методів, що легко читаються, замінюються на випадкові літери для оптимізації розміру файлу. В результаті обфускація робить код складним для розуміння, тому що ці скорочені імена не є абревіатурами реальних імен, а просто випадкові літери. Ось тут і + + вступають в гру маппінги. + +Маппінг — це просто заміна одного імені на інше, в більшості випадків з обфускованого на читабельне. Кожен маппінг може також містити додаткові метадані, такі як документація. Набір маппінгів називається "набором маппінгів" або просто "маппінгами". Ви можете уявити набір маппінгів як словник перекладу, де кожен маппінг — це переклад слова на іншу мову. У цьому випадку обфусковані імена — це мова, яку використовує комп'ютер, а словник допомагає перекласти це на звичайну англійську. + +Однак маппінги між версіями Minecraft не є сталими: наприклад, `DirtBlock` може бути обфусковано як `abc` у версії 1.19, але в 1.20 він може бути обфусковано як `def`. Тому важливо мінімізувати зміни обфускації між версіями, і це вирішується за допомогою проміжних маппінгів, які перетворюють обфусковані імена в такі, що не змінюються між версіями, але все одно не читаються по-англійськи. Quilt використовує Hashed Mojmap, де кожен клас, поле і метод префіксуються як `C_`, `f_` і `m_` відповідно, за якими слідує 8-символьний хеш. + +Коли ви розробляєте моди, ви часто будете бачити проміжні маппінги Fabric, які використовують префікси `class_`, `field_` і `method_`, за якими слідує число. Mojang також публікує офіційні маппінги, які часто називаються Mojmap (скорочення від Moj(ang)-map(pings)) для кожної версії після 1.14. Оскільки вони не мають проміжного набору маппінгів, вам потрібно буде зробити додаткові кроки, щоб використовувати їх замість інших маппінгів. На щастя, Loom виконує цей процес за вас, тому вам не потрібно хвилюватися про заміну маппінгів у вашому моді на офіційні від Mojang. + +Існує кілька різних форматів для збереження маппінгів, і на момент написання цієї статті розробляється новий формат з багатьма покращеннями. В нашій екосистемі найчастіше використовується формат [Tiny V2], який використовує один файл `.tiny` для збереження маппінгів, а поля і методи розміщуються як "дочірні" елементи для їх батьківських класів. Іншим часто використовуваним форматом є формат Enigma, який використовує структуру каталогів, де для кожного верхнього рівня класу є файл, а всі елементи організовані у вигляді дерева, де кожен клас, метод і поле є дочірнім елементом іншого класу. + +### Редагування маппінгів + +Набори маппінгів не обов'язково повинні містити маппінг для кожного класу, поля або методу в jar-файлі, щоб бути дійсними; насправді більшість наборів маппінгів не є повними. Наприклад, маппінги Quilt (скорочено QM) досягають 99% завершеності на даний момент. У середовищі розробки, немаппіровані елементи будуть використовувати проміжні імена замість обфускованих, тому якщо ви коли-небудь переглядали код Minecraft із застосуванням QM або Yarn від Fabric, ймовірно, ви бачили кілька проміжних імен. Це ще гірше з параметрами методів: оскільки вони схильні до змін між версіями, вони (зазвичай) не мають проміжних імен, і імена, які ви бачите в коді, залежать від інструментів, які ви використовували для декомпіляції гри. + +Якщо ви хочете додати ім'я або змінити неправильне або погане, або додати документацію в код, ви можете почати з вибору набору маппінгів, на основі якого будете працювати. У цій статті ми будемо використовувати QM, хоча процес для Yarn майже ідентичний. Якщо ви хочете працювати з маппінгами Mojang, вам потрібно буде зробити кілька додаткових кроків, які ми не будемо покривати тут. Якщо ви хочете працювати з QM, ми настійно рекомендуємо ознайомитись з його [документацією по внеску][QM CONTRIBUTING.md] і внести зміни в репозиторій. Вам знадобляться базові знання Git, але це повинно бути досить легко, якщо ви вже працювали з Git. + +Щоб почати, отримайте свою власну копію коду [Quilt Mappings] через клонування або завантаження репозиторію. Якщо ви хочете в подальшому внести свій вклад, пряме завантаження коду не спрацює, вам потрібно буде [форкнути репозиторій][fork qm] і клонувати вже цей форк. + +Коли у вас буде код, виконайте команду `./gradlew mappings` в командному рядку або терміналі, щоб запустити [Enigma], наш улюблений інструмент для редагування і запису маппінгів. Рай написав чудовий [посібник з редагування маппінгів в Enigma][Enigma guide], так що ви можете ознайомитись з ним і почати працювати з маппінгами! Після того як ви завершите редагування, не забудьте зберегти зміни перед закриттям Enigma. + +### Внесення змін назад у Quilt + +Щоб внести зміни, потрібно додати і зафіксувати зміни, а потім відправити їх у ваш форк QM. Це дуже легко зробити через IDE, як описано в [статті по налаштуванню](../introduction/setting-up), але якщо хочете, можна зробити це і через командний рядок або термінал за допомогою таких команд. + +```bash +git add . # повідомити git, щоб відстежувати всі зміни в поточній директорії + +git commit -m "Blabla" # додати зміни в новий коміт (замініть "blabla" на короткий опис ваших змін) + +git push # завантажити ваші коміти в ваш форк QM. Можливо, вам потрібно буде додати `origin `, якщо git скаржиться на відсутню гілку upstream +``` + +Після того як ви відправите зміни у ваш форк, перейдіть на вкладку [Pull Requests][QM PRs] і натисніть кнопку "Compare & Pull Request" у примітці про ваші нещодавні зміни. Заповніть заголовок і опис вашого PR, відправте його і чекайте, поки ваші зміни будуть розглянуті і прийняті. Більш детальне пояснення процесу PR можна знайти в [документації по внеску][QM CONTRIBUTING.md]. + +### Використання відредагованих маппінгів + +Якщо ви не хочете вносити зміни назад у Quilt або хочете спробувати їх у середовищі розробки, ви можете виконати команду `./gradlew publishToMavenLocal`, щоб зробити потрібні файли доступними для інших проектів на вашому комп'ютері. Тепер ви можете перейти в проект, де хочете застосувати ці маппінги, і відредагувати файл `build.gradle`, додавши `mavenLocal()` в блок `repositories`, якщо його там ще немає. + +```gradle +repositories { + // ... + mavenLocal() +} +``` + +Як тільки ви додасте `mavenLocal()`, ви можете відредагувати файл `libs.versions.toml` у директорії `gradle/`, щоб змінити версію маппінгів, які ви використовуєте, на тільки що відредаговану. У разі з QM ви можете замінити суфікс `+build.*` на `+local`; інші проекти можуть використовувати інший формат версій, тому вам потрібно буде перевірити їх документацію або код для уточнення. + +```diff + minecraft = "1.20.4" +-quilt_mappings = " + +2.0.0+build.0" ++quilt_mappings = "2.0.0+local" +``` + +Тепер ви можете запустити проект, і всі зміни, які ви внесли в маппінги, будуть доступні у вашому середовищі розробки.