Перейти к содержимому
Korean Random

Рекомендуемые сообщения

(редактировалось)

English documentation is attached to this post.

 

Всем привет,

 

Меня зовут Антон, я работаю в WG и занимаюсь модами и смежными штуками.

 

В следующей версии танков мы реализовали новую фичу для облегчения инсталяции/деинсталяции модов - пэкеджи пакеты модов. По предложениям трудящихся переименовали в пакеты.

 

К посту я приаттачил доку с описанием текущей реализации. Важный момент: все это work in progress, и то, что в следующей версии эта фича появится в танках, не означает, что мы остановим ее разработку. Мы хотим и будем доделывать и переделывать какие-то вещи согласно вашим пожеланиям, поэтому считайте это только первой итерацией разработки.

 

В ближайших нескольких версиях танков будет работать гибридное подключение модов - и через пакеты, и по старинке через res_mods/. В будущем в силу ряда причин мы бы хотели отойти от способа установки модов через res_mods/; тем не менее мы не будем этого делать, пока коммьюнити мододелов не скажет, что пакеты ок и вы готовы перейти на них полностью. Поэтому нам очень важно получать от вас отзывы и предложения по улучшению системы, чтобы мы могли учитывать их в будущих версиях.

 

Миша завел гуглодоку, за актуальными хотелками можно следить там: https://docs.google.com/document/d/1-IIs7gEUbOb82ZfEeJhdC8LyF64EU_sXzOnMp2nahuE/edit?usp=sharing

 

update 12.10.17

 

Прикрепил обновленную русскую доку (v0.5) packages_doc_0.5_ru.pdf. Отдельное большое спасибо Mixaill за работу над документом.

 

В 9.20.1 починили ряд багов:

  • Неполная регистронезависимость имён в VFS
  • Некорректная загрузка локаций из пакетов
  • Невозможность загрузки Gettext-файлов из VFS

 

Английскую версию сейчас допереводим, приаттачу, как только будет готова

 

Updated the document to v0.5.

 

 

packages_doc_0.5_en.pdf

Изменено пользователем ribbed
  • Нравится 22
  • Не нравится 11

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Миша приди, список хотелок принеси!

  • Нравится 5
  • Не нравится 3

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(редактировалось)

Несколько предложений:

 

1. Прописать в спецификации рекомендованный путь конфигурационных файлов, например

/mods/configs/ИМЯ_ПАКЕТА/

2. Изменить механизм реализации версионности пакета.

Как я понял, сейчас все пакеты с одинаковым идентификатором будут грузиться в алфавитном порядке названий файлов.

Было бы логично грузить только пакет крайней версии.

Устаревшие пакеты складировать куда-то в 

/mods/deprecated/

3. Вместо файла load_order.txt ввести систему разрешения конфликтов, как это сделано в Linux у APT или RPM

 

То есть, в meta.xml добавить возможность указания:

  • зависимых пакетов
  • конфликтных пакетов.

 

4. Вместо каталога с текущей версией, добавить возможность указания совместимых версий в meta.xml

 

То есть пакет хранится например в /mods/packages/packageName.wotmod

А в meta.xml указывается

<supportedVersions>
  <version>0.9.17.0.1</version>
  <version>0.9.17.0.2</version>
</supportedVersions>

Также, было бы неплохо иметь возможность указывать поведение при отсутствии текущей версии клиента в списке поддерживаемых: игнорирование или прекращение загрузки пакета.

 

5. Добавить возможность хранить в пакете файлы для разных версий клиента

 

Например, в таком виде:

/package.wotmod
/package.wotmod/meta.xml
/package.wotmod/default/
/package.wotmod/0.9.17.0.2/

Сначала загружается контент из default, потом загружается контент из папки с текущей версией клиента.

Изменено пользователем Mixaill
  • Нравится 10
  • Не нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Инжектор, органайзер. На худой конец модменеджер. Это, по крайней мере, более знакомо. Тем более что это, как я понимаю, аналог Nexus Mod Manager.

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Mixaill

 

 

 

Прописать в спецификации рекомендованный путь конфигурационных файлов, например

В принципе, да, можно. Тут уже от вас хотелось бы хотелки услышать, а мы добавим в спецификацию.

 

 

 

Как я понял, сейчас все пакеты с одинаковым идентификатором будут грузится в алфавитном порядке названий файлов. Было бы логично грузить только пакет крайней версии
 

Это сделано для того, чтобы можно было выпускать патчи к большим модам. Например, выходит Зимний мод с пакетом в 2гб, через пару дней - фикс к нему на 10мб. Лучше же скачать фикс, а не перекачивать полностью весь мод.

 

Остальные хотелки зафиксировал, будем обсуждать. Кстати, может, гуглодоку ту оживишь, чтоб всем удобней было отслеживать? Я в первом посте кину линк на нее.

 

@Наглый Котэ

 

 

 

Тем более что это, как я понимаю, аналог Nexus Mod Manager.
 

Нет, это не NMM, а просто поддержка нового способа подключения модов на уровне движка игры.

Про свой мод менеджер мы уже давно думаем и с пакетами на него будет проще перейти, но тем не менее это проект точно вне скоупа этой фичи.

  • Нравится 4
  • Не нравится 4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(редактировалось)

Идея крутейшая. Только один вопрос - как быть с конфигами для таких модов, как тот же всеми любимый PMOD?

При установке модпака - установщик еще можно обучить засовывать нужный конфиг в пакадж. А как быть при ручной установке?

 

И еще. Такой подход либо начисто убьет JSON-конфиги, либо как минимум усложнит их чтение/запись (ОСОБЕННО запись). Нужно будет обучать мод редактировать архив с собой.

Вариантом может стать переход на ResMgr + XML, но время показало, что XML-ки более громоздки как по внешнему виду содержимого, так и по коду обработчика.

И потом, ResMgr в пакаджи все равно писать не будет. Не умеет он.

 

Можно создать папку res/<версия_игры>/configs/<имя_мода>, но это уже будет нарушением предлагаемой концепции.

 

И это еще без учета таких вещей, как шкурки с зонами пробития, вернее, функционал их парсинга, реализованный в Ремодомоде, который пакаджи будет по полчаса пережевывать вместо текущих 10 минут.

 

Продолжил чтение спецификации. Файл meta.xml, в принципе, тоже можно под JSON переписать. Вы не подумайте, что я такой весь поклонник этого формата, но по мне, Human Readable и XML - понятия несколько не стыкующиеся.

 

С файлом load_order тоже интересная история. Клиент не начнет случаем рушиться, если мода, который в нем прописан, нет в папке?

Потому что если начнет - модпакерам еще одна тонна геморроя подъедет.

Изменено пользователем Polyacov_Yury
  • Нравится 2
  • Не нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(редактировалось)
Можно создать папку res/<версия_игры>/configs/<имя_мода>, но это уже будет нарушением предлагаемой концепции.

Хранить конфиги за пределами пакета - вполне себе нормальная идея (других вариантов как-то нет).

Только я предлагаю другой путь для хранения (см. выше)

 

Нужно будет обучать мод редактировать архив с собой.

Убивает всю идею пакетов. Он должен быть неизменяем. В идеале, с лежащей рядом хэшсуммой или ЭЦП.

 

Продолжил чтение спецификации. Файл meta.xml, в принципе, тоже можно под JSON переписать. Вы не подумайте, что я такой весь поклонник этого формата, но по мне, Human Readable и XML - понятия несколько не стыкующиеся.

В делом да, JSON или YAML смотрелись бы лучше.

Изменено пользователем Mixaill
  • Нравится 1
  • Не нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Polyacov_Yury,

 

Конфиги точно должны лежать вне пакета. Пакет должен быть неизменяемой сущностью, которую просто закинул в папку и она там статичная лежит.

 

Как вам обрабатывать конфиги и в каком формате их вести - это на ваше усмотрение, но лучше все-таки определиться с конкретными папками для конфигов, как и предлагал Миша.

  • Нравится 1
  • Не нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Описание дезориентировало. Тогда не понимаю смысла. Просто из пути "скачать->распаковать->скопировать->играть" исчез пункт распаковать. Зато появились вопросы "А чем мне открыть wotmod, чтобы изменить настройки" Так зачем размножать папки, если часть модов все-равно должна будет лежать в свободном доступе для редактирования? Ради прицела и простенькой дамаг панельки отдельный механизм, ну такое... Это только ИМХО.

  • Нравится 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тогда не понимаю смысла.

Согласен. Данная фича реализовывалась правкой paths.xml.

Ничего интересного...

  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(редактировалось)

Зато появились вопросы "А чем мне открыть wotmod, чтобы изменить настройки"

Настройки снаружи

 


 

^^^^ - это первый шаг к созданию чего-то вроде репозитория модов с автообновлением и блекджеком. Главное чтобы снова res-mods.ru не получился

 

Согласен. Данная фича реализовывалась правкой paths.xml.

Ничего интересного...

А банки можно через engine_config.xml грузить. Но ни то, ни другое не является нормальным.
Изменено пользователем Mixaill

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

лучше все-таки определиться с конкретными папками для конфигов
Ага. С учетом того, что на данный момент мест для конфигов как минимум 3 (res_mods/configs, res_mods/version/.../mods/, res_mods/version/.../mods/mod_name), думаю, с унификацией проблем не будет НИКАКИХ. ( :heh:) Нет, это все вполне реорганизуемо, но все же :)

 

Нет, идея с пакаджами очень даже замечательная, всецело поддерживаю.

Вот только сейчас еще одна мысль в голову пришла. У нас же есть такие моды, которые сами по себе особо ничего не делают, но обширно используются другими (ButtonReplacer или modsListApi, например). Тогда мод уже из нескольких пакаджей состоять будет, получается?) Это если про мое применяемое в десятке моих же модов пресловутое PYmodsCore не вспоминать.

 

И да, еще мысль возникла. Каталог для скриптов модификаций (scripts/client/gui/mods) останется на месте?

 

И как наличие пэкаджей отразится на всеми нами любимом paths.xml?

 

А, вот еще. (меня прорвало, да :D) Можно ли тогда сделать файлы .wotmod шифруемыми? К примеру - банальным паролем. Да, надо придумать, как этот самый пароль беспалевно предоставлять игре...

Но это решило бы проблему нарушения авторских прав и одновременно с этим исчезла бы необходимость обфусцирования скриптов модификаций.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Описание дезориентировало. Тогда не понимаю смысла.

 

Дело в том, что эти самые пакеты нужны только для крупных модов где много файлов разных форматов (типа XVM или типа переделанных моделей) и где разработчик мода постоянно или периодически что-то меняет в этих файлах. И вот для таких случаев удобно распространение мода в виде пакета и чтоб клиент игры поддерживал работу с этими пакетами.

 

В остальных случаях оно не нужно и не требуется. Папка res_mods в текущей её реализации будет проще и удобнее.

  • Нравится 3
  • Не нравится 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот только сейчас еще одна мысль в голову пришла. У нас же есть такие моды, которые сами по себе особо ничего не делают, но обширно используются другими (ButtonReplacer или modsListApi, например). Тогда мод уже из нескольких пакаджей состоять будет, получается?) Это если про мое применяемое в десятке моих же модов пресловутое PYmodsCore не вспоминать.

Поэтому предлагаю идею с зависимостями, а не load_order.txt, который хз кто будет составлять.

 

И да, еще мысль возникла. Каталог для скриптов модификаций (scripts/client/gui/mods) останется на месте?

Как я понимаю да,но было бы хорошо, если в meta.xml можно было бы указывать entrypoint.

 

И как наличие пэкаджей отразится на всеми нами любимом paths.xml?

В нем появилась одна новая запись. (Зачем вы вообще в него лезете?)

 

решило бы проблему нарушения авторских прав и одновременно с этим исчезла бы необходимость обфусцирования скриптов модификаций.

Да нет никакой проблемы.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
(редактировалось)
Но это решило бы проблему нарушения авторских прав и одновременно с этим исчезла бы необходимость обфусцирования скриптов модификаций.

Проблема авторских прав есть только в мыслях любителей шифрования и обфусцирования, которые не понимают, что на самом деле моды уже принадлежат ВГ, а не авторам. Читай пользовательское соглашение.

 

 

 

Да нет никакой проблемы.

+100

Изменено пользователем Yupi
  • Нравится 2
  • Не нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обновил первый пост, добавил ссылку на гуглодоку с хотелками. На всякий случай дублирую здесь: https://docs.google.com/document/d/1-IIs7gEUbOb82ZfEeJhdC8LyF64EU_sXzOnMp2nahuE/edit?usp=sharing

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Дело в том, что эти самые пакеты нужны только для крупных модов где много файлов разных форматов (типа XVM или типа переделанных моделей) и где разработчик мода постоянно или периодически что-то меняет в этих файлах
Так почему не запилить свой NMM с картошкой и ВБРом, а множить кучу папок, которые все равно будут использоваться только наполовину?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

моды уже принадлежат ВГ
Принадлежность и авторство вещи таки разные.
  • Нравится 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>При этом файлы разных модов располагаются в одних и тех же папках

Сейчас мы имеем кучу mod_ файлов, будет куча *.wotmod (конфиги-же у нас вынесены в другое место ;-) )

 

>В общем случае система пэкеджей не допускает ситуации, когда в папке res/ внутри разных пэкеджей находятся одинаковые файлы.

Т.е. вариант когда несколько модов используют одну и туже библиотеку не рассматривали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

>В общем случае система пэкеджей не допускает ситуации, когда в папке res/ внутри разных пэкеджей находятся одинаковые файлы.

Т.е. вариант когда несколько модов используют одну и туже библиотеку не рассматривали?

библиотека выносится в свой отдельный пакет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу

×