SyDr, отлично!
Хотя для примера хочу, чтобы в формате json описания были как образцовые. Сейчас займусь, сегодня и загружу обновление, скорее всего

Всё верно для Вога указал или что подправить? )
Например, plugins заполнить или entry?

Создал папку Screenshots, поместил туда logo.png, но менеджер не видит.
/Screens сработало.

Баг. Если перейти на вкладку снимков экрана и щёлкнуть по картинке, то дальше содержимое других вкладов и списка модов отображаться не будет.
Баг 2. Редактирование мода. Переключаю язык на английский. Выбираю «из файла». Вставляется обрезанная часть файла:
    HMMIII In the Wake of Gods (WoG) is an expansion pack to the Heroes of Might and Magic III Shadow of Death game. You must have Heroes III Shadow of Death installed prior to installing the expansion.


Вижу, там просто ограничение на длину поля. Оно реально необходимо? )
Кажется понял: это краткое описание фигурирует в репозитории.

P.S.S. Определить мод к одной категории крайней сложно. Чаще всего, как в репозиториях Цивы, один мод занесён сразу в несколько рубрик.

Quote:Всё верно для Вога указал или что подправить? )
Например, plugins заполнить или entry?

Может китайский вообще из комплекта удалить? Всё равно уже много лет никто не обновляет языковой файл.

Quote:Баг. Если перейти на вкладку снимков экрана и щёлкнуть по картинке, то дальше содержимое других вкладов и списка модов отображаться не будет.

А ты ещё раз нажми

Quote:Вижу, там просто ограничение на длину поля. Оно реально необходимо? )
Кажется понял: это краткое описание фигурирует в репозитории.

Ну... Как-никак это же короткое описание

Из всего что я встречал:
1) short description очень редко используется
2) priority используется только некоторыми людьми для своих непубличных модов (и поэтому у меня не планов на повторную реализацию этого механизма)
3) compatibility entries Валерий заполнял для пары модов, мне кажется что также практически не используется
4) mod_version используется при установке для сравнения с установленной версией, особо ни на что не виляет
5) platform и info_version не используются
6) plugins это объект (см. выше пример):
никто никогда не использвовал (там бага :D, оно не работает)
так что надо денёк подождать до обновы
7) category - любимая вещь Валерия

Quote:P.S.S. Определить мод к одной категории крайней сложно. Чаще всего, как в репозиториях Цивы, один мод занесён сразу в несколько рубрик.

Да, надо tags. Но ты считай, что category - это нечто фундаментальное, т.е. если можно писать gameplay, то никаких graphics, interface и scenarios уже не будет.

И вообще, нечего сообщение обновлять быстрее, чем я на него отвечсаю

Вышла версия 0.93.6.2

Китайский языковой файл удалён из комплекта поставки. Если он вам больше не нужен - удалите его самостоятельно после обновления.
Поправлен баг в функционале (именование и описание плагинов), которым никто не пользовался.

SyDr, а что стало с идеей указывать моды, от которых мод зависит? Например, поставка со всеми выключенными модами. Но включаешь один, а он автоматом включает ещё 3 или просит включить.

Была отложена до лучших времён. В AutoIt с большим числом модов даже вычисление совместимости модов было долгим занятием (хотя, может я стал немного лучше и теперь мог бы сделать нормально), поэтому самый приоритетный мод (несовместимый хоть с чем-то) считался мастером и подсказки считались только для него.

В принципе, вариант с просьбами включить зависимости можно реализовать и в этой ветке (AutoIt) за пару дней, не дожидаясь годами, пока я напишу всё с нуля на C++/Lua.

Нужно ли?

Без этой функции очень сложно разбить один мод на несколько или выпустить только мод с новыми событиями, которые будут использовать другие. Вот сейчас Era Scripts и Remagic дублируют файл-мод с правками багов SoD, Era Scripts включает era hooker плагин и два события для него от Игрика. Всё это делает моды несовместимыми и неустойчивыми. А бедда в том, что авторам сложно надеяться на то, что люди не будут запускать их моды без разрешения зависимостей. Так что Depends я бы очень хотел, при чём по возможности с сохранением порядка, в каком обязательные моды перечислены. Мы как-то обсуждали варианты реализации. В моём тогдашнем понимании моды группировались в группы либо с фиксированным порядком, либо без оного. Сами группы имели фиксированный порядок.

[группа 4 фиксированная]
Phoenix Mod верхний над всеми

[группа 3 нефиксированная]
...

[группа 2 нефиксировнная в плане порядка модов внутри группы]
Fast Battle Animation
New Hints
New Music
New Events

[группа 1 фиксированная]
WoG Rus - русификация всегда после WoG
WoG


При генерации modlist.txt по возможности учитывался бы порядок модов, указанных в зависимостях:
ValeryMap depends on:
- fred objects patch (этот по возможности должен быть выше morn)
- morn object patch

Пространство для таких перестановок обеспечивается существованием групп с нефиксированным порядком.

Ты, помню, что-то схожее предлагал, но несколько другое?

https://bitbucket.org/SyDr/era-ii-mod-ma...ew-default

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

1) Выкинуть всю поддержку compatibility и priority на базе модов вообще (либо оставить частично для тестов мододелам)
2) Ввести глобальный мастер-лист и обновлять его централизованно (пример LOOT - https://github.com/loot/skyrimse/blob/v0...list.yaml)
2.5) Авторы модов и продвинутые пользователи могут делать pull-request'ы
3) ММ, соответственно, может его автоматически обновлять у себя (а ведь механизм уже практически готов - есть ведь самообновления самой программы)
4) Простенький вариант* может быть быстро** сделан и протестирован нами. Или всеми принудительно :D


*В духе подсветить их в списке и предложить что-нибудь включить и подвигать в списке
**Относительно времени жизни вселенной.

К глобальным спискам отношусь скептически. Централизованно, в любой момент можно забить + крайне неудобно. Ну делают у себя китайцы моды, так чего мне пытаться выяснить их зависимости?

Quote:Но вообще, похоже это не очень хорошая идея, позволять модам управлять приоритетами других модов

Известно что — разрешать по определённому алгоритму.

Побочный эффект зависимостей — возможность устанавливать недостающие моды автоматически с репозитория. В принципе, можно разбить ответственность. DLL или отдельный исполняемый файл будет генерировать modlist.txt, а менеджер модов только вызывать программу/функции и редактирвоать mods.json другого формата, где буду отражено только пользовательское закрепление модов (а также статусы: активен/нет). Если ты будешь не против и я найду время, то можем так скооперативиться.

Quote:К глобальным спискам отношусь скептически.

А локальные - это тоже самое, только сначала их надо будет слить вместе из 50 установленных модов.

Quote:Централизованно, в любой момент можно забить + крайне неудобно.

Забить и так всегда можно . Неудобство то в чём? Вот, например, выпустил кто-то мод на 150 Мб, но зависимости изменились. Что, опять 150 Мб качать? Или выдавать пользователям инкрементальный апдейт?

Quote:Ну делают у себя китайцы моды, так чего мне пытаться выяснить их зависимости?

Вот зависимости, как раз, можно и авторам модов оставить.

Quote:Известно что — разрешать по определённому алгоритму.

ValeryMap depends on:
- fred objects patch (этот по возможности должен быть выше morn)
- morn object patch

BersMap depends on:
- morn objects patch (этот по возможности должен быть выше fred)
- fred object patch

То есть, другими словами, это нормально, что:
Phoenix Mod говорит, что зависит от: WoG

Но ненормально, что он говорит:
WoG Rus идёт после WoG. Это должен сам WoG Rus писать (а лучше в одном месте записать).
Phoenix Mod верхний над всеми. А если кто-то скажет, что он выше?

Централизованный подход выкидывает целый пласт проблем, связанных с необходимостью сливать информацию из кучи модов вместе, а потом каким-то образом решать конфликты между ними (а они ведь будут). И вариант "доверяем более приоритетным модам" тоже не вариант.

Ну и плюс такой вариант на AutoIt я точно не потяну .

Quote:В принципе, можно разбить ответственность. DLL или отдельный исполняемый файл будет генерировать modlist.txt, а менеджер модов только вызывать программу/функции и редактирвоать mods.json другого формата, где буду отражено только пользовательское закрепление модов (а также статусы: активен/нет). Если ты будешь не против и я найду время, то можем так скооперативиться.

Новый ММ работает с list.json (правда, инфу об активности он игнорирует и использует из list.txt, но потом я это уберу):

Quote:Вот, например, выпустил кто-то мод на 150 Мб, но зависимости изменились. Что, опять 150 Мб качать? Или выдавать пользователям инкрементальный апдейт?

В современное время редко кто занимается микроуправлением с инкрементальными обновлениями. Например, разработчики CMS Joomla за годы проблем пришли к выводу, что каждое обновление будет полным дистрибутивом (у кого файлы какие удалены, как переименованы, как измененены — всё перепишется). Я тоже теперь за полные сборки. Собственно, уже и радуюсь инструменту по сборке Эры автоматом.

Quote:Но ненормально, что он говорит:
WoG Rus идёт после WoG. Это должен сам WoG Rus писать (а лучше в одном месте записать).
Phoenix Mod верхний над всеми. А если кто-то скажет, что он выше? Sm

Нормально, если он знает, что так нужно и так играет.

Моды — просто порядок наложения файлов друг на друга. Если я включая зависимости в сборку в виде файлов, как сейчас плагины тащатся и дублируются, то либо всё в один мод забиваю (выполняя ручное наложение файлов), либо через installmod гарантирую порядок активации. Это нормально. Конфликт будет (уровня совета), если два мода захотят видеть другие два в разном порядке.

Quote:ValeryMap depends on:
- fred objects patch (этот по возможности должен быть выше morn)
- morn object patch

BersMap depends on:
- morn objects patch (этот по возможности должен быть выше fred)
- fred object patch

Идеальный пример. В карте Валерия объекты Фреда должны перекрыть при совпадении объекты Морна, а в моей наоборот (я поклонник полей боёв от Морна, не Фреда). Пользователь будет извещён о противоречии, но поскольку карта Валерия установлена последней, то её и послушаем в плане порядка. Тем не менее, в списке противоречий моего мода будет конфликт с настройками ValeryMap.

Если же порядок зависимостей не важен, то формально всё хорошо, зависимости разрешены. Однако предполагается, что зависимости не имеют перекрывающихся файлов. А это наивно )

Quote:Централизованный подход выкидывает целый пласт проблем, связанных с необходимостью сливать информацию из кучи модов вместе, а потом каким-то образом решать конфликты между ними (а они ведь будут).

Нажатием кнопки в ММ на конкретном моде: «Устранить конфликты», после чего модификации конфликтующие на основе явно прописанных зависимостей, отключаются. Напомню, в зависимостях можно указывать и неупорядоченные наборы модов:

BersMap:
[
    ["fredobjects", "mornobjects"] // порядок не фиксирован, лишь бы были объекты
]

ValeryMap:
[
    "mornobjects", // порядок фиксирован
    "fredobjects"
]

Вот теперь два мода совместимы и порядок будет диктовать карта Валерия.

Quote:Новый ММ работает с list.json

Ты начал переписывать его или это старый новый?

/P.S. Можем временно отложить упорядочивание модов и зависимости, пока не будет DLL с простым API по работе с ними. Удобно вызывать из AutoIt внешние функции с соглашением stdcall?

Quote:Собственно, уже и радуюсь инструменту по сборке Эры автоматом.

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

Quote:многа букав...

Ладно, я уже почти убеждён. Почти.

Мне теперь (вот не прям щас, а уже какое-то время) не нравится замут с упорядоченными группами неупорядоченных групп. Тут есть кое-какие мысли, но их надо ещё чуть-чуть поварить...

Quote:/P.S. Можем временно отложить упорядочивание модов и зависимости, пока не будет DLL с простым API по работе с ними. Удобно вызывать из AutoIt внешние функции с соглашением stdcall?

Можем. Удобно. Но мне будет больно.

Quote:Ты начал переписывать его или это старый новый?

Даже не знаю. Это мой маленький кораблик Тесея. По крайней мере теперь когда я сажусь что-то писать, то получается намного быстрее. Сейчас он на стадии... ну скажем, как самый старый ММ через пару дней после выпуска. Ну только что работает быстрее и моды можно скрывать/показывать. Хотя... Он это и раньше умел. Пока я всё не сломал :D. В старом ММ я столько функционала наговнокодил, что теперь прямо и не знаю что быстрее делать, а что отложить на потом .

Ахах, старый добрый Сидр )))

Quote:Мне теперь (вот не прям щас, а уже какое-то время) не нравится замут с упорядоченными группами неупорядоченных групп.

Упорядоченной можно оставить только корневую группу

мод 1
мод 2
[мод 3, мод 4, мод 5, мод 6] - неупорядоченная
мод 7

Quote:В старом ММ я столько функционала наговнокодил, что теперь прямо и не знаю что быстрее делать, а что отложить на потом

Знакомо ))) Я от наследия Эры < 2 тоже со скрипом пытаюсь уйти )

Рапортуют о баге с HC:

Quote:If I use newest Mod Manager and I select EraHD_exe it does not use it and takes normal Era_exe

Не умеет менеджер запускать файлы с пробелами в именах, не экранирует всю строку, запускает первое слово, остальное аргументами идёт.
h3era HD.exe запускает h3era.exe

(07.12.2017 14:43)Berserker Wrote:  Рапортуют о баге с HC:

Quote:If I use newest Mod Manager and I select EraHD_exe it does not use it and takes normal Era_exe

Не умеет менеджер запускать файлы с пробелами в именах, не экранирует всю строку, запускает первое слово, остальное аргументами идёт.
h3era HD.exe запускает h3era.exe

У меня нормально запускает.

igrik, я тоже сперва спутал менеджер модов со стартовым меню. Но дело именно в Менеджере Модов, где есть список модов и выбор исполняемого файла для запуска.